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ABSTRACT 


This  work  is  an  analysis  of  the  use  of  a  multilevel 
secure  computer  system  to  execute  tactical  combat 
applications  programs.  Using  the  Gemini  Trusted  Multiple 
Microcomputer  Base,  currently  under  evaluation  by  the 
Department  of  Defense  Computer  Security  Center,  applications 
and  test  programs  were  written  and  implemented  in  order  to 
expose  some  characteristics  of  the  system. 

Using  a  Janus/Ada  compiler  with  the  necessary  library 
alterations  for  the  Gemini  machine,  a  simple  weapons 
application  program  was  implemented  in  a  system  designed  to 
simulate  a  tactical  environment  where  classified  material 
can  be  handled  in  spite  of  the  different  levels  of  security 
held  by  the  operators  that  can  access  the  system. 

The  loss  in  performance  due  to  the  secure  operating 
system's  overhead  is  estimated  in  order  to  establish  the 
tradeoffs  in  performance  gains  due  to  parallel  processing 
capability  of  the  multiprocessor  system. 
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INTRODUCTION 


I  . 

A.  PROBLEM  STATEMENT 

This  thesis  investigates  the  use  of  a  multilevel  secure 
computer  system  in  a  tactical  combat  environment.  The 
specific  application  of  the  system  proposed  is  to  perform 
the  duties  of  a  real-time  system  with  the  extra  ability  to 
handle  sensitive  information  in  a  trusted  manner. 

A  real-time  system  is  defined  as: 

A  system  that  reacts  as  to  affect  the  environment  in  which 
it  is  operating.  It  is  a  collection  of  devices, 
controlled  by  a  stored  program  of  instructions.  This 
program  acts  as  the  regulating  element  in  a  feedback  loop, 
which  then  forms  part  of  a  system.  [Ref.  1:  p.lj 

Sensitive  information  is  defined  as  a  collection  of  data 
that  cannot  be  accessed  but  by  those  who  have  specific 
authorization . 

The  type  of  environment  where  a  secure  tactical  system 
can  be  implemented  is  shown  in  Figure  1.1  ,  which  depicts  a 
hypothetical  section  of  the  operation's  room  of  a  combat 
ship. 

The  tactical  program  executed  by  this  specific  system 
requires  some  secret  data,  in  order  to  produce  the  desired 
results.  The  system  should  allow  the  tactical  program  to 
access  the  secret  data,  make  the  necessary  computations  and 
transfer  the  result  to  the  desired  peripheral.  The  operator 
who  "drives"  the  tactical  program  should  not  have  direct 


database 


Figure  1.1  A  Tactical  Secure  Environment 


access  to  the  secret  data.  The  eventual  access  to  tne 
secret  data.  i.e.  to  update  some  parameters,  should  be 
allowed  only  to  operators  with  secret  clearance  or  above. 

Another  important  aspect  of  a  tactical  secure  combat 
system  is  that  the  tactical  program  needs  to  be  maintained 
by  on-board  technicians,  who  might  not  have  secret 
clearance.  If  a  "free"  access  to  the  secret  data  is 
allowed,  a  skillfull  maintainer  with  some  corrupt 
intentions,  can  easily  produce  a  "patch"  which  will  extract 
the  sensitive  information  and  transfer  to  a  printer  or  a 
display.  This  dangerous  picture  is  very  much  likely  tc 
exist  and  in  fact,  such  a  problem  ocurred  two  years  ago  on 
board  of  an  aircraft  carrier,  involving  the  geographic 
positions  of  U.S.  Navy's  nuclear  submarines. 

In  order  to  avoid  the  necessity  to  clear  all  tne 
raaintainers  on-board  to  secret  level,  some  sort  of 
independence  should  exist  between  the  modules  of  a  tactical 
program.  The  modules  should  be  able  to  receive  different 
security  labels  that  cannot  be  changed  by  on-board 
maintenance-.  The  modules  authorized  to  be  maintained  on 
board  should  be  re-integrated  into  the  system  with  no 
changes  to  the  security  parameters. 

Since  tactical  environment  automatically  calls  for 
speed,  all  the  necessary  security  techniques  must  not  create 
too  much  overhead  to  the  overall  performance. 
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This  research  was  performed  m  conjunction  with  the 
Naval  Postgraduate  School’s  AEGIS  Modelling  Group.  This 
group  is  sponsored  by  the  AEGIS  Combat  System  Project  Office 
to  conduct  research  in  the  area  of  combat  system 
development . 

To  summarize  the  problems  discussed  in  this  section  we 
can  state  the  following  requirements  for  a  tactical  secure 
combat  system: 

1)  The  system  will  execute  tactical  programs  that  uses 
sensitive  information; 

2)  The  access  to  the  sensitive  information  should  be 
controlled ; 

3)  -  The  tactical  programs  need  to  have  an  on-board 
-maintenance  by  technical  personnel  with  no  clearance 

to  the  sensitive  information; 

4)  Changes  to  the  security  parameters  should  not  be 
possible  unless  by  authorized  personnel; 

5)  There  should  be  no  large  overhead  due  to  the  security 
aspects  of  the  system. 

B.  PROPOSED  SOLUTION 

This  thesis  proposes  the  use  of  a  multilevel  secure 
computer  system  to  execute  the  tactical  combat  program.  The 
secure  computer  system  would  be  the  "heart"  of  the  proposed 
system,  executing  the  application  program  specifically 
designed  for  each  different  situation.  The  multilevel 
secure  computer  system,  based  upon  the  security  level  of  the 
operator  currently  logged  on,  would  perform  different  kinds 
of  functions.  The  capacity  of  labeling  the  modules  of 
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execution  in  a  multilevel  secure  computer  system  would  allow 
the  isolation  of  sensitive  modules,  thus  protecting  them 
against  unauthorized  users . 

An  schematic  view  of  the  proposed  solution  is  shown  in 
Figure  1.2. 

Here,  an  application  program  would  be  delivered  to  the 
ship's  system  containing  five  independent  modules.  Module  1 
is  the  "master"  module,  which  controls  the  execution  of  the 
whole  system  and  performs  the  synchronization  between 
modules.  It  would  not  be  permitted  to  maintain  this  module 
on-board.  Modules  2  and  3  contain  algorithms  to  process 
inputs  and  outputs  and  some  intermediate  calculations . 
Those  modules  can  be  maintained  on-board.  Module  4  accesses 
the  secret  data,  and  cannot  be  maintained  on-board.  Module 
5  contains  the  secret  data,  and  cannot  be  maintained 
on-board  although  alteration  of  some  specific  fields  can  be 
done  by  an  authorized  operator. 

when  an  unclassified  operator  logs  on,  the  master  module 
will  activate  modules  2  and  3,  which  will  execute  and  call 
module  4  to  access  the  secret  data.  The  secret  data  is 
then,  handled  only  by  module  4  which  provides  the  result  of 
the  operation  requested  by  modules  2  and  3.  but  will  never 
transmit  the  information  read  from  module  5. 

When  a  "secret"  operator  logs  on,  the  master  module  will 
activate  directly  module  4,  which  accesses  module  5,  but 
this  time  the  information  read  is  transferred  to  the 


M3DULE  2 
PROCESS 


MODULE  1 


Figure  1.2  A  Secure  Processes  Interaction 
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operator  whose  "secret”  classification  level  authorizes 
access  to  the  information. 

There  are  several  systems  being  currently  evaluated  by 
the  Department  of  Defense  to  operate  as  a  multilevel  secure 
system.  The  Gemini  Trusted  Multiple  Computer  Base  is  the 
one  used  in  this  research.  This  system  is  still  undergoing 
development  and  so,  some  restrictions  were  imposed. 

C.  THESIS  FORMAT 

This  thesis  is  composed  of  five  chapters  ordered  in  a 
sequence  to  provide  the  reader  with  a  presentation  of  the 
problem,  some  background  information  in  secure  systems  and 
then  introduce  the  design  and  the  implementation  of  a  system 
to  execute  tactical  secure  combat  programs. 

Chapter  I  presents  the  problem  and  the  solution  in  a 
generic  format. 

Chapter  II  describes  the  concepts  of  multilevel  security 
and  provides  some  detailed  information  about  the 
microcomputer  used  in  this  research,  the  Gemini  Trusted 
Multiple  Computer  Base. 

Chapter  III  discusses  the  actual  design  of  the 
application  program  for  the  proposed  system. 

Chapter  IV  covers  the  implementation  and  testing  of  the 
application  program  using  the  Gemini  system.  Some 
information  about  loss  in  performance  due  to  overhead  caused 
by  security  checks  is  included  in  chis  chapter. 
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cnapter  v  analyses  tne  results,  proposes  some  techniques 
for  the  development  of  applications  programs  and  suggests 
some  follow-up  research. 


A.  TRUSTED  COMPUTER 
1 .  Background 

There  is  not  to  date  an  unique  and  generally 
accepted  definition  for  a  trusted  computer  system. 
Depending  on  the  origin  (i.e.,  business  or  government),  the 
requirements  can  be  quite  different  and  sometimes  they  even 
conflict  between  each  other.  The  Department  of  Defense, 
with  the  purpose  to  define  parameters  for  any  work  in  the 
area-'-  of  secure  systems,  has  elaborated  a  document  which  is 
entitled  DOD  Trusted  Computer  System  Evaluation  Criteria  and 
was  published  in  1983  [Ref.  2] .  ,  This  document  established 
guidelines  for  the  test  and  evaluation  of  any  new  system 
involving  security  aspects.  It  contains  all  the  information 
necessary  to  anyone  involved  in  research  with  trusted 
computer  systems. 

One  of  the  important  concepts  described  in  this 
publication,  which  has  direct  effect  in  the  analysis 
executed  in  this  thesis,  is  the  establishment  of  two  basic 
types  of  security  policy:  Mandatory  (sometimes  called  Non- 
discretionary )  and  Discretionary  Security. 

Mandatory  Security  is  defined  by  the  following 
direct  quote. 


Security  policies  defined  for  systems  that  are  used  to 
process  classified  or  other  specifically  categorized 


sensitive  information  include  provisions  for  the 
enforcement  of  mandatory  access  control  rules.  That  is. 
must  include  a  set  of  rules  for  controlling  access  based 
directly  on  a  comparison  of  the  individual’s  clearance  or 
authorization  for  the  information  and  the  classification 
or  sensitivity  designation  of  the  information  being 
sought,  and  indirectly  on  considerations  of  physical  and 
other  environmental  factors  of  control.  The  mandatory 
access  control  rules  must  accurately  reflect  the  laws , 


regulations,  and  general  policies  from  which  they  are 
derived.  [Ref.  2:  p.72] 

As  it  can  be  understood  from  the  definition  above, 
the  mandatory  policy  is  expressed  by  a  lattice  of  access 
classes.  The  mandatory  policy  establishes  that  the  control 
of  the  accesses  is  based  on  an  access  level  determined  by 
the  user's  security  clearance  and  this  policy  cannot  be 
modified  or  bypassed  within  the  system.  The  mandatory 
policy,  furthermore,  establishes  the  limits  for  the 
discretionary  security,  -which  is  an  additional  set  of 
constraints  on  access  to  information,  based  on  some 
particular  constraint,  like  the  military  "need- to-know" 
policy . 

The  Discretionary  Security  is  the  second  type  of 

security  policy  established  by  the  DOD  document  and  it  is 

expressed  by  direct  quote  which  follows. 

Security  policies  that  are  defined  for  systems  that  are 
used  to  process  classified  or  other  sensitive  information 
must  include  provisions  for  the  enforcement  of 
discretionary  access  control  rules.  That  is,  they  must 
include  a  consistent  set  of  rules  for  controlling  and 
limiting  access  based  on  identified  individuals  who  have 
been  determined  to  have  a  need-to-know  for  the 
information.  [Ref.  2:  p.  73] 
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There  will  be  certain  situations  where  although  the 
elements  of  a  group,  involved  in  an  analysis  or  a  research 
project  may  have  the  same  clearance,  the  manager  wants  to 
limit  the  type  of  information  which  each  one  should  access. 
This  can  be  done  in  order  to  extract  different  ami  unbiased 
opinions  and  observations.  The  discretionary  policy  is  the 
tool  to  provide  this  access  granularity  without  affecting 

i 

the  mandatory  rules. 

2 .  The  Threats 

The  attractive  field  of  computer  technology  has  had 
in  the  past  few  years  one  of  the  fast  and  impressive 
developments  ever  observed  in  a  new  science.  This  has  lead 
to  a  proliferation  of  computers  and  networks  so  that  it  is 
improbable  to  find  today  any  company  or  organization  that 
does  not  use  some  kind  of  a  computer  system. 

Among  all  the  information  stored,  some  is 
classified,  and  so,  need  special  care.  The  few  and  basic 
security  controls  first  used  were  considered  sufficient  to 
limit  the  access  to  classified  information.  The  machines 
were  physically  isolated  and  locked.  Some  more 
sophisticated  systems  had  a  software  coded  control.  As  it 
has  always  happened  in  human  history,  there  is  always  a 
conflict  of  interests  and  there  is  almost  no  limit  to  the 


human 

desire 

and 

dedication . 

So, 

the  computer  "hackers" 

entered 

the 

scene 

and 

there 

has 

been  a  lot  of  break-ins 

widely 

reported  by 

the 

press , 

in 

many  types  of  computer 
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systems.  The  control  processes  had  to  be  improved  and  tne 
break-in  techniques  improved  concurrently! 

The  only  very  low  break-in  probability  technique  ended 
up  to  be  the  enclosure  of  the  peripheral,  which  permits 
access  to  the  classified  information,  in  a  tightly  secured 
vault.  Evidently  this  is  not  a  satisfactory  solution.  In 
some  tactical  applications.  for  instance,  the  operators 
might  have  no  secret  clearance,  but  the  data  the  tactical 
program  uses,  is  secret.  A  bright  and  "interested"  operator 
can  use  this  situation  to  create  a  software  patch,  for 
example,  which  although  transparent  to  the  normal  operation 
of  -.the  system,  will  extract  some  of  the  classified 
information  that  is  stored  somewhere. 

3 .  Proposed  Technology 

Research  centers  and  universities  have  conducted  a 
great  amount  of  work  and  fortunately,  some  very  good  results 
are  now  available  to  be  implemented.  The  security  kernel 
technology  [Ref.  3]  has  been  considered  the  driving  force 
for  the  building  of  trusted  computer  systems  and  several 
products  have  implemented  and  improved  this  technique  in  an 
effort  to  turn  the  products  into  practical,  simple  to  use. 
and  most  of  all,  secure  systems. 

To  determine  if  a  system  is  secure  or  not,  is  a  very 
difficult  task,  starting  with  the  problem  to  establish  the 
criteria  to  evaluate  the  performance.  The  Departament  of 


Defense  is  preparing  a  document  which  will  contain  the 


details  of  such  an  evaluation  criteria  and  this  analysis  is 


not  considered  in  this  work. 

The  employment  of  secure  products  by  potential 
customers  is  usually  not  considered  until  some  harmful 
break-in  happens,  mainly  because  the  practicality  of  its  use 
has  not  been  demonstrated  yet.  In  the  tactical  environment 
there  are  extra  concerns  like  timing,  adaptability  and  real¬ 
time  applicability  that  have  to  be  demonstrated  together 
with  the  secure  capabilities,  in  order  to  integrate  these 
products  into  a  combat  system. 

The  Gemini  Trusted  Multiple  Microcomputer  Base  using 
the  'Gemini  Multiprocessing  Secure  Operating  System  iGEMSOS; 
is  claimed  by  its  manufacturers  to  fulfill  the  tactical 
requirements  with  secure  aspects,  and  this  was  the  machine 
used  in  this  research. 

B.  THE  GEMINI  SYSTEM 
1 .  General 

The  Gemini  Multiprocessing  Secure  Operating  System 
(GEMSOS)  was  designed  for  the  Gemini  Trusted  Multiple 
Microcomputer  Base,  in  order  to  have  the  system  to  operate 
at  the  B3  [Ref.  2]  level  of  classification,  although  the 
ultimate  goal  is  to  meet  the  class  A1 ,  the  highest  level 
defined.  The  system  is  currently  under  evaluation  by  the 
Department  of  Defense  Computer  Security  Center  for 
certification  to  the  B3  class.  The  system  was  developed 
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based  on  the  security  kernel  technology  [Ret.  3]  like  all 


trusted  systems  are,  and  the  main  idea  was  to  provide  an 
of f -the-shelf  product,  using  state  of  the  art,  hardware 
components  and  software  engineering  techniques.  The  main 
characteristics  of  the  system  are  [Ref.  4]: 

1)  Can  operate  with  up  to  eight  Intel  APX-286  based 
microcomputers  in  parallel,  giving  a  great  processing 
power.  The  microcomputers  communicate  through  shared 
memory  segments  providing  high  throughput,  and  the’ 
GEMSOS  minimizes  bus  contention  by  locating  data  and 
code  in  the  local  memory  of  each  processor,  whenever 
it  is  possible. 

2)  The  multiple  microcomputers  are  capable  of 
multiprocessing  and  multiprogramming.  The  GEMSOS  can 
multiplex  processes  to  a  single  processor  or 
distribute  processes  to  several  processors,  so  that 

v  both  parallel  and  pipeline  processing  is  possible. 

3)  Concurrent  computing  is  independent  of  the  programming 
language  used,  since  the  GEMSOS  provides  its  own 
primitives  to  manipulate  the  abstracts  eventcounts  and 
sequencers .  in  order  to  support  communication  and 
synchronization  among  processes. 

4)  A  variety  of  I/O  devices  and  storage,  which  include 
fixed  disks,  high  density  floppy  diskette  drives  and 
non-volatile  memory,  can  be  directly  connected  to  the 
Multibus.  Each  RS-232  interface  board  can  handle  up 
to  eight  devices . 

5)  The  system  includes  some  other  features  like  a  real 

time  clock,  data  encryption  device  (NBS-DES 

algorithm) ,  a  system  unique  identifier  to  prevent 
covert  channels ,  and  a  non-volatile  memory  to  store 
passwords  and  encryption  keys . 

The  Gemini  system  allows  the  development  of 
applications  programs  using  theoretically  any  language 
supported  by  the  CPM-86  operating  system.  Some  additional 
files,  which  will  change  the  utility  library  associated  with 
the  programming  language,  has  to  be  provided  with  the  Gemini 
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system . 


As  the  decision  was  to  generate  application 


software  using  the  Janus/Ada  computer  language,  the  actual 
coding  of  this  work  had  to  wait  the  delivery  of  the 
Janus/Ada  environment  software  and  documentation,  which 
happened  in  late  March.  There  are  special  features  for  the 
Gemini  Janus/Ada  environment  that  cannot  be  easily  adapted 
from  a  normal  Janus/Ada  code  and  these  will  be  pointed  out 
later  in  this  work.  The  current  implementation  of  Janus/Ada 
on  GEMSOS  still  does  not  include  the  ability  to  use  a 
Janus/Ada  process  as  the  initial  Ring  1  process  and  some 
limitations  result  from  that. 

"  The  claimed  ability  to  handle  different  hardware 
configurations  is  an  important  characteristic  of  the  Gemini 
system.  If  the  system  is  going  to  be  used  in  real  tactical 
applications,  this  certainly  is  an  important  aspect. 

2 .  Resource  Management  Concepts 

A  set  of  resource  management  services  that  can  be 
invoked  by  an  application  program  is  provided  by  the  GEMSOS , 
in  order  to  provide  the  customer  with  tools  to  control  the 
performance  of  the  particular  implementation  under 
development.  The  application  program  uses  what  is  called  a 
service  call,  which  can  be  treated  as  a  subroutine  call, 
with  arguments  being  passed  and  returned.  These  service 
calls  are  called  gate  calls,  since  they  make  certain 
security  checks  to  allow  the  flux  of  data.  The  actual 
details  of  each  call  is  specific  to  the  language  being  used 

23 


and  is  supplied  in  the  gemsos  interface  library  provided 
witn  each  compiler  (Janus/Ada  in' this  study). 


The  GEMSOS  kernel  is  divided  into  three  basic 
management  areas,  which  are:  segment  management,  process 
management  and  device  management. 


if 


a .  Segment 

Segments  are  discreet  and  logical  objects 
(entities)  that  contain  all  the  information  to  be 
manipulated  in  a  Gemini  system.  The  segments  of  concern  to 
the  applications  programmer  are  the  code,  data  and  stack 
segments . 


The  GEMSOS  kernel  allows  some  application 
program  to  move  data  within  the  system  in  such  a  way  as  to 
be  immediate  available  to  a  particular  process  or  not. 


There  are  eight  different  calls  provided  for  tnis 
management.  These  calls  will  handle  the  movement,  creation 
and  termination  of  data  as  well  as  the  transfer  of  the 


necessary  information  to  the  Kernel's  mandatory  security 
model,  which  will  deny  or  accept  the  request  for  service. 
The  segment  manager  controls  a  "Known  Segment  Table"  (KST). 


where  the  segment  numbers  are  related  to  the  system-unique 
identifier  of  the  segment  usable  by  the  memory.  The  segment 
when  created,  will  receive  a  tag  associating  it  to  a 
particular  collection  of  segments,  called  a  volume,  which  is 
the  unit  of  secondary  storage.  A  volume  can  be  treated  as 
separate  entity  and  so  be  called  by  a  process.  A  detailed 
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description  about  each  of  the  segment  management  calls  is 
contained  in  [Ref.  5]. 

b.  Process 

The  management  of  a  process  includes  the  actual 
management  and  the  synchronization  between  processes . 

(1)  Management .  When  created,  each  process  is 
uniquely  identified  by  code,  stack  and  data  segments  and  at 
the  same  time,  a  fixed  amount  of  resources  is  assigned  to 
it.  There  are  four  primitives  to  manage  a  process. 

(2)  Synchronization.  Once  a  segment  is  created 
in  an  application  program,  an  eventcount  and  a  sequencer  are 
automatically  associated  with  it.  These  two  abstract 
objects  have  the  same  name  as  their  owning  segment.  The 
process  can  then  be  synchronized  with  other  processes  by 
means  of  four  primitives  supported  by  the  kernel,  which  are.- 
advance,  await,  read  and  ticket. 

c.  Device 

The  Gemini  system  treats  the  management  of 
devices  in  a  very  peculiar  way,  which  is,  to  reside  most  of 
the  functions  dealing  with  I/O  management  in  the  code  at  the 
application  level.  This  design  is  two-fold.  It  reduces  the 
size  of  the  kernel  making  verifications  easier,  but  it  also 
makes  the  I/O  applications  software  more  difficult  to  be 
coded.  There  are  six  calls  to  handle  a  device.  The  I/O 
device  controller  is  treated  as  a  process,  which  is  then 
synchronized  with  the  segments  eventcounts  and  sequencers  to 


perform  the  desired  functions.  More  information  about 
device  management,  process  management  and  synchronization, 
can  be  found  in  [Ref.  5]. 

3 .  The  Operating  System 

The  Intel  APX-286  supports  four  protection  levels 
and  GEMSOS  uses  them  as  four  hierarchical  rings  to  enforce 
the  security  layering.  They  are  numbered  from  0  to  3,  0 
being  the  most  privileged  one.  The  mandatory  and 
discretionary  policy  are  supported  in  rings  0  and  1 
respectively.  The  mandatory  policy,  as  already  mentioned, 
cannot  be  modified  and  is  represented  as  a  lattice  of  access 
classes  in  the  distributed  kernel  contained  in  ring  0.  This 
distributed  kernel  in  ring  0  will  virtualize  processors . 
storage,  I/O  and  objects  {processes,  segments  and  devices). 
Ring  1  supports  the  discretionary  policy  and  any  other 
security  requirements.  The  supervisor,  which  is  built  on 
the  kernel,  uses  the  virtualized  objects  to  perform  the 
normal  functions  of  an  operating  system.  The  other  two 
rings,  2  and  3,  are  used  by  the  programmers  for  the 
development  of  applications . 

The  implementation  of  a  reference  monitor  [Ref.  3J 
is  the  base  of  the  GEMSOS.  All  the  access  by  the  active 
entities,  subjects,  to  passive  entities,  objects,  has  to  be 
mediated  by  the  reference  monitor  as  shown  in  Figure  2.1. 

All  these  checks  are  performed  by  the  security 
kernel  located  in  ring  0.  The  subjects  are  processes 
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allowed  to  perform  in  a  specific  domain,  and  objects  are 
pieces  of  information  that  are  observed  or  modified.  Both 
have  security  labels  assigned  to  them.  The  result  of  the 
comparison  between  the  security  labels  of  the  subjects 
versus  the  objects,  is  what  decides  if  the  transaction  is 
approved . 


Figure  2.1  The  Functions  of  a  Reference  Monitor 


security  label  is  a  tag  mat  represents  the  access 


class  of  an  entity.  This  access  class  is  defined  as  having 
two  components:  a  compromise  level  and  an  integrity  level. 
There  are  properties  that  establish  the  criteria  for  an 
access  to  be  granted  based  on  the  compromise  and  integrity 
protection  enforcement  rules.  These  properties  are  listed 
in  [Ref.  4:  pp.  16,17]  and  are  summarized  here  as  follows: 
Compromise  Properties . 

1;  If  a  subject  has  "observe”  access  to  an  object,  the 

compromise  access  component  of  the  subject  must 
dominate  the  compromise  access  component  of  the 

object . 

2)  If  a  subject  has  "modify"  access  to  an  object,  the 

-  compromise  access  component  of  the  object  must 
dominate  the  compromise  access  component  of  the 

subject . 

Integrity  Properties. 

1)  If  a  subject  has  "modify"  access  to  an  object,  then 

the  integrity  access  component  of  the  subject 
dominates  the  integrity  access  component  of  the 

object . 

2)  If  a  subject  has  "observe"  access  to  an  object,  then 
the  integrity  access  component  of  the  object  dominates 
the  integrity  access  component  of  the  subject. 

Compromise  can  be  related  to  the  secure  distribution 

of  information,  and  integrity  to  the  secure  modification  of 
information.  "Dominates"  in  the  above  properties,  means 
access  level  greater  than  or  equal  to  the  referred  entity. 

The  number  1  property  of  both  compromise  and 
integrity  protections  are  the  traditional  security  policies 
which  are  called  simple  security  properties.  They  state 
that  in  order  to  observe/modify  some  information  one  has  to 
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have  a  clearance  at  least  equal  to  or  greater  than  the 
information  referenced. 

The  number  2  property,  on  the  other  hand,  is  not 
usual  and  it  is  called  the  ‘-property  (star  property) .  The 
purpose  of  this  protection  is  to  avoid  an  indirect 
observation  or  modification  of  an  entity  by  an  "inferior” 
one.  In  the  compromise  situation,  for  example,  a  secret 
process  could  modify  an  unclassified  file  if  this  protection 
did  not  exist.  This  "modification”  could  easily  be  the 
transmission  of  secret  data  that  the  secret  process  has 
access,  to  the  unclassified  file.  In  the  integrity 
situa'tion,  it  prevents  a  secret  process  of  observing  an 
unclassified  file,  and  this  observation  could  be  "read  some 
data  and  include  it  in  your  computation",  which  will  allow 
the  secret  process  to  be  influenced  by  an  unclassified  user. 
In  [Ref.  6]  there  are  some  more  comments  about  the  types  of 
attacks  (Trojan  Horse)  that  can  result  if  these  properties 
are  not  enforced. 

Ring  integrity  is  enforced,  in  addition  to  all  those 
properties  already  mentioned,  in  the  Gemini  system.  It 
means  that,  subjects  can  only  access  objects  with  equal  or 
greater  ring  number,  which  enforces  the  hierarchical 
structure  of  the  rings . 

The  rigid  observance  of  the  properties  mentioned 
above,  would  transform  the  simple  task  of  distributing 
messages  (when  they  have  different  access  classes),  into  a 


very  complicated  and  resource  consuming  procedure. 
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Gemini  system  is  a  multilevel  system,  this  would  De  tne 
case.  In  order  to  avoid  this  proDlem,  the  '-property  for 
compromise  and  integrity  are  relaxed  within  a  certain  range 
of  security  levels.  The  process,  which  has  certain 
flexibility  in  order  to  execute  some  trusted  activities,  is 
called  "trusted'*  subject,  and  it  is  up  to  the  application 
programmer  that  his  "trusted"  process  does  not  violate  the 
security  policies.  In  GEMSOS,  the  implementation  of 
"trusted  subjects"  are  in  the  form  of  multilevel  subjects 
and  they  are  trusted  within  a  range,  demarcated  by  their 
maximum  and  minimum  access  classes.  As  mentioned  already, 
only  subjects  guaranteed  not  to  improperly  observe  or  modify 
information,  should  be  created  as  multilevel  subjects. 
Extreme  caution  should  be  emphazised  when  interfacing  with 
devices . 

The  range  of  access  classes  for  devices,  should  be 
chosen  depending  on  the  physical  location  in  which  they 
operate.  Devices  can  be  single  level  or  multilevel,  and  the 
classification  is  based  on  the  data  they  manipulate . whether 
they  have  a  security  label  attached  to  it  or  not. 

The  security  properties  of  single  and  multilevel 
devices  are  the  following  [Ref.  4:  pp.  21,22]: 
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Single-level  Devices. 

1)  To  receive  ("read")  information.- 

Process  maximum  compromise  >=Device  minimum  compromise 
Device  maximum  integrity  >=Process  minimum  integrity 

2)  To  send  ( "write”)  information: 

Device  maximum  compromise  }=Process  minimum  compromise 
Process  maximum  integrity  }=Device  minimum  integrity 

Multi-level  Device. 

1)  To  receive  ("read")  information: 

Process  maximum  compromise  }=Device  maximum  compromise 
Device  minimum  integrity  }=Process  minimum  integrity 

2)  To  send  ("write")  information: 

Device  minimum  compromise  }=Process  minimum  compromise 
Process  maximum  integrity  }=Device  maximum  integrity 


The  NPS  conf ieuration 


The  Gemini  system  used  during  this  research  has  the 
following  configuration: 

1)  one  Intel  APX-286  microcomputer 

2)  two  1.2  Mbyte  floppy  disk  drives 

3)  one  RS-232  interface  board  with  a  maximum  of  eight 
ports 

This  system  proved  to  be  sufficient  for  the 
execution  of  some  preliminary  processes  like  the  ones 
presented  in  this  thesis.  However,  the  amount  of  time 
expended  during  compilation,  linking  and  sysgening  and  the 


constant  swapping  of  floppy  disks  due  to  the  floppy  disk 
drive  environment  was  a  big  constraint. 
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TACTICAL  SYSTEM  DESIGN 


A.  DESIGN  ISSUES 
1 .  Ob iectives 

The  primary  objective  of  this  design  was  to  develop 
a  model  which  would  demonstrate  the  use  of  the  Gemini 
Trusted  Multiple  Computer  Base  in  a  tactical  combat 
environment.  Based  on  the  requirements  for  a  tactical 
secure  combat  environment  listed  in  the  introductory 
chapter,  the  model  shown  in  Figure  3.1  is  presented. 

In  this  model ,  the  Gemini  computer  would  be  used  to 
receive  the  encoded  data  from  a  tracker  radar,  and  transmit 


some  positioning 

information  to  a 

weapons 

device . 

The 

actual  devices 

being  controlled 

in  this 

model . 

are 

irrelevant  at  this  point.  The  application  program  executed 
by  the  Gemini  computer  would  make  use,  for  the  computation 
of  the  results,  of  some  stored  information  classified  as 
secret.  This  can  be  better  understood,  if  we  suppose  that 
the  tracker  radar  is  tracking  an  incoming  missile,  and  the 
desired  response,  is  the  firing  of  a  chaff  burst  as  a 
defensive  procedure.  During  the  computation  phase,  the 
program  has  to  access  data  about  our  own  ship  which  might  be 
classified.  The  operator  controlling  the  tactical  picture 
cannot  have  direct  access  to  his  data.  However  this  data 
has  to  be  updated  eventually  by  some  authorized  operator. 
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In  addition  to  all  tnat,  the  system  has  to  nave  a 
very  fast  response,  and  the  steps  of  execution  (reception  of 
radar  data,  computation  of  results,  transmission  or 
position)  have  to  be  precisely  synchronizea . 

2 .  Hardware  Simulation 

The  construction  of  the  model  described  in  the 
previous  section,  would  be  ideal,  since  the  attachment  of 
different  devices  to  the  Gemini  computer  would  be  tested. 
Response  time,  encoding  input  techniques  and  many  other 
aspects  would  be  revealed.  This  should  be  part  of  a  follow¬ 
up  research. 

As  a  preliminary  research,  the  development  of  the 
application  program  was  considered  the  main  task. 

The  complete  model,  will  then  be  simulated  as 
follows:  One  terminal  attached  to  a  serial  port  is  going  to 
simulate  the  radar  input.  The  values  sent  to  the  "main" 
process  will  be  generated  by  software.  Another  terminal 
will  perform  the  same  simulation  of  the  weapon  to  be  driven, 
showing  on  the  screen  the  transmitted  values.  The  "main" 
process  will  make  use  of  the  secret  data  stored  in  another 
segment,  simulating  a  secondary  storage. 

These  simulations  will  not  disturb  the  development 
of  the  application  program.  The  processes  to  be  created  in 
order  to  perform  the  simulations  described  above,  would  be 
necessary  in  the  complete  model  as  well.  The  main 


difference  would  be  in  the  code  itself,  since  the  processes 
would  be  executing  controlling  functions. 

B.  SOFTWARE  DESIGN 

The  application  software  for  this  system  was  designed 
using  the  modular  programming  construction  technique.  In 
the  particular  case  of  the  system  used,  which  had  a  floppy 
disk  environment,  this  technique  was  very  useful,  because 
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the  modules  could  be  compiled  separately.  Unfortunately, 
the  testing  of  the  modules  cannot  be  done  separately,  when 
the  modules  execute  calls  to  the  GEMSOS.  To  prepare  a 
program  to  be  executed  in  the  Gemini  computer,  which  is 
going-  to  be  explained  in  a  further  section,  takes  about  15- 
17  minutes,  and  the  main  process  (the  parent  process)  has  to 
be  included  always,  since  the  creation  of  processes  and 
synchronization  are  coded  in  the  main  process. 

The  application  software  was  then  divided  in  four 
application  programs: 

1)  "THEMAIN" ,  the  parent  process,  containing  the 
initialization,  creation  of  processes,  synchronization 
and  deletion  of  processes ( log  off). 

2)  "RADAR",  a  child  process,  performing  the  simulation  of 
the  radar  inputs,  and  the  transmission  of  data  to  the 
parent  process . 

3)  "COMPUTE",  a  child  process,  which  receives  data  from 
the  "RADAR"  process,  execute  some  computations,  and 
tramsmit  the  results  to  the  "CHAFF"  process. 

a)  "CHAFF",  a  child  process,  which  will  receive  data  from 
the  "COMPUTE"  process,  and  will  simulate  the 
positioning  of  a  weapon. 


1 .  The  Parent  Process 

This  is  the  controlling  process  for  the  whole 
system.  The  creation  of  the  child  processes  is  established 
in  this  module,  together  with  the  security  parameters  and 
the  synchronization  scheme.  This  module  has  to  be  designed 
and  coded  by  a  programmer  cleared  to  the  maximum  level  of 
security  to  be  used,  since  he  will  decide  the  levels  for 
each  of  the  child  processes  to  be  created.  The  coding  of 
the  child  modules,  will  be  given  to  different  programmers, 
depending  upon  the  security  level  of  the  module. 

The  general  algorithm  for  a  parent  process  is  shown 
in  Figure  3.2. 


Package  body  THEMAIN  is 
begin 

perform  initialization; 

create  segment  „o  be  parent ; 

create  segment  to  perform  synchronization; 

create  processes ; 

loop 

call  child  1 ; 
call  child  3; 
call  child  2; 
exit  when  some  condition; 
end  loop; 
delete  processes ; 
end  THEMAIN; 


Figure  3.2  Package  THEMAIN 
There  are  some  other  procedures,  to  transfer  data  to 
and  from  the  child  processes,  not  shown  here.  They  can  be 
found  in  the  program  listing  in  Appendix  A. 


36 


o 


The  Child  Processes 


These  processes  will  perform  some  defined  function 
which  has  oeen  determined  by  the  software  manager.  The 
actual  details  of  implementing  the  code  are  left  to  the 
programmer  in  charge. 

In  our  application  program,  the  child  modules 
execute  the  general  algorithm  described  in  Figure  3.3. 

This  is  just  a  general  algorithm,  and  the  full 
listing  of  each  module  used  in  the  application  program 
developed  in  this  research,  is  shown  in  Appendix  A. 


Package  CHILD  body  is 
begin 

receive  data  from  parent; 
perform  calculation; 
execute  simulation; 
pass  data  to  parent; 
end  CHILD; 

Figure  3.3  Package  CHILD 

As  it  was  mentioned  before,  the  child  processes  can 
be  maintained  separately,  as  long  as  the  synchronization 
part  of  each  module  is  not  changed.  If  a  module  is  to  be 
labelled  as  secret,  the  maintenance  can  be  restricted  to 
Authorized  personnel.  The  preparation  of  the  complete 
program  to  be  executed  in  the  system,  will  be  done  by  a  user 
with  the  necessary  level  of  security. 
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C.  SOFTWARE  DESIGN  GOALS 

The  configuration  used  for  this  research  had  some 
restrictions,  as  already  mentioned,  and  among  them,  the 
amount  of  time  necessary  for  each  development  step 
represented  considerable  difficulty.  The  GEMSOS  calls  using 
the  Janus/Ada  language  are  yet  under  development.  A 
preliminary  version  of  the  Janus/Ada  software  library  and 
manuals  were  received  in  March  86.  Due  to  these  reasons, 
the  following  sequence  of  steps  has  been  established  for  the 
development  of  the  application  program: 

1)  Demonstrate  the  attachment  and  detachment  of  a 
terminal . 

2) '  Demonstrate  an  application  program  which  samples  an 

input  device,  performs  calculations,  and  presents  the 
result,  all  synchronized  sequentially. 

3)  Extract  some  information  about  overhead  caused  by  some 
GEMSOS  calls. 

4)  Synchronize  the  application  program  via  a  real-time 
clock . 

5)  Label  one  of  the  child  processes  as  secret,  and  test 
the  access  for  different  operators. 

This  research  was  performed  in  cooperation  with 
another  student,  Major  Miguel  Reyes,  Peruvian  Air  Force, 
who  has  one  more  quarter  to  work  on  this  system.  Hopefully, 
the  steps  not  accomplished  by  this  thesis  would  be 
demonstrated  in  his  work. 


IV. 


IMPLEMENTATION  ON  GEMINI  SYSTEM 


A.  GEMSOS  LIBRARY 

When  developing  Janus/Ada  application  programs  to  run  on 
GEMSOS,  the  standard  I/O  and  file  type  utilities  provided 
with  the  normal  Janus/Ada  compiler,  cannot  be  used. 
Instead,  the  GEMSOS  gate  calls  provided  by  the 
manufacturers,  have  to  be  used.  As  the  Janus/Ada 
environment  provided  for  use  with  the  GEMSOS,  is  not 
complete  yet,  some  of  the  utilities  necessary  for  the 
development  of  the  application  program  had  to  be 
constructed.  Four  packages  were  built  to  modularize  the 
procedures,  functions  and  declarations  necessary  for  the 
present  application:  MANAG,  GEMIO,  CRPROCE ,  TABLES. 

1 .  Package  MANAG 

This  package  includes  the  procedures  necessary  for 
the  management  of  segments  and  terminals .  To  create  a 
segment,  a  number  of  parameters  should  be  passed  to  the 
GEMSOS  call  CREATE_SEGMENT .  These  parameters  are  then 
explicitly  passed  in  this  procedure. 

Any  device  to  be  used  by  the  Gemini  system  needs  to 
be  attached.  This  applies  to  the  screen  terminal  as  well. 
The  GEMSOS  call  ATTACH_DEVICE ,  has  a  specific  configuration 
parameters  which  are  used  with  terminals .  The  same  applies 
for  the  GEMSOS  call  DETACH  DEVICE.  Two  procedures  were  then 


built,  m  such  a  way  that  some  parameters  which  are 
constants  for  terminals  do  not  have  to  be  passed. 

2 .  Package  GEMIO 

This  package  is  designed  to  be  the  I/O  package  for 
the  Gemini  system.  The  procedures  included  here,  are  the 
ones  found  to  be  necessary  up  to  this  point  of  the  research. 
Evidently,  many  more  have  yet  to  be  developed,  in  order  to 
have  a  comprehensive  I/O  package.  Some  of  the  procedures 
included  in  this  package  were  taken  from  the  demonstration 
program  supplied  by  the  manufacturers  of  the  Gemini 
computer . 

3-.  Package  CRPROCE 

In  order  to  create  a  process,  the  general  algorithm 
presented  in  Figure  4.1  has  to  be  applied. 


Package  body  CREATE  A  PROCESS  is 
begin 

raakeknown  the  mentor  segment 

specify  the  address  for  the  process  stack 

specify  the  address  for  the  process  code 

specify  the  address  for  the  process  mentor 

specify  the  address  for  the  trap  segment 

calculate  the  stack  size 

create  the  segment  for  the  stack 

makeknown  the  segment  for  the  stack 

swap  in  this  segment 

create  the  segment  for  data 

raakeknown  the  segment  for  data 

swap  in  this  segment 

complete  the  record  for  the  CREATE_PROCESS  call 
call  the  GEMSOS  CREATE_PROCESS 
end  CREATE  A  PROCESS 


Figure  4.1  Package  CRPROCE 


As  it  can  be  seen  from  Figure  4.1,  the  creation  of  a 
process  involves  a  large  number  of  steps.  The  size  of  this 


procedure  alone,  justifies  the  construction  of  a  package 
containing  just  this  procedure. 


The  purpose  of  this  package  is  to  concentrate  a 
great  number  of  the  declarations  necessary  for  the 
implemented  application  program.  Since,  as  already 
mentioned,  the  utilities  programs  coded  in  Janus /Ada  have 
not  yet  all  been  delivered,  some  procedure  to  supply  the 
parameters  necessary  for  the  create  and  makeknown  calls,  had 
to  be  built.  For  the  time  being,  a  simple  loop  that  will 
generate  fixed  numbers  is  what  will  be  used.  A  correct 
procedure,  which  will  look  for  the  next  free  number  to 
allocate,  should  be  done  in  the  future.  This  package  has  a 
preliminary  procedure  to  load  access  classes  yet  to  be 
tested . 


B.  PROCESS  STRUCTURE 

1 •  Pathname  Convention 

Since  all  information  in  the  Gemini  system  is  stored 
in  segments,  some  method  to  make  reference  to  these  segments 
is  needed.  A  pathname  is  the  shorthand  method  used  for  this 
purpose  of  aliasing  a  segment.  It  consists  of  a  sequence  of 
entry  numbers  that  together  define  all  of  the  mentor 
segments  to  a  particular  segment.  The  pathname  ”3,8" 


indicates  that  the  target  segment  is  at  entry  ©  of  its 


mentor  segment,  which  itself  has  entry  3  in  the  system 
mentor  segment.  Pathnames  may  be  up  to  5  entry  numbers  long 
in  the  present  implementation. 

The  pathname  is  used  during  the  generation  of  a 
program  to  run  in  the  secure  environment,  and  it  will  be 
explained  in  the  next  sections. 

2 .  Ring  1  Environment- 

The  current  implementation  of  Janus/Ada  on  GEMSGS 
does  not  allow  the  use  of  a  Janus/Ada  process  as  the  initial 
Ring  1  process.  The  Ring  1  Login  and  the  Ring  i  Loader 
provided  have  to  used  in  order  to  run  Janus/Ada  programs . 

Another  restriction  imposed  by  this  preliminary 


version 

is  that, 

the 

file 

R1TRAP.CMD,  which  contains  the 

trap  handler  and 

debugger , 

has 

to  be  svseened 

( to  be 

discussed 

later)  , 

at 

entry 

six 

off  the  system 

mentor 

segment . 

Figure 

4.2 

shows 

the 

Ring  i  environment 

segment 

naming  hierarchy.  The  segments  which  have  fixed  "positions" 
in  the  ring  i  structure  are  shown  in  Figure  <* .  2 ,  which  are: 

1)  SSAT-  System  Segment  Aliasing  Table;  containing  the 
bootstrap  and  kernel  segments . 

2)  Vlloader-  Ring  1  loader  code  segment. 

3)  Vllogon-  Login  process  code  segment. 

4)  NV.DS  at  5,0-  Shared  segment  for  loader  processes. 

5)  NV.DS  at  5-  Appliccation  Root 


6)  Rltrap-  Trap  entry  and  debugger 


NV.DS 


LOGIN 


Figure  4.2  Ring  1  Structure 

The  entry  of  concern  for  the  applications 
programmer,  is  entry  number  5.  In  the  current 
implementation,  this  is  the  position  were  the  application 
program  should  be  located . 

3.  Application  Program  Environment 

The  application  program  developed  in  this  research, 
is  composed'  of  four  segments.  The  mentor  segment  for  the 
code  segments  (the  application  mentor)  will  be  at  entry  5 


off  the  system  mentor.  The  mentor  segment  for  tne  stack  and 
data  segments  will  be  at  entry  5  off  the  application  mentor. 
The  parent  process  will  be  located  at  entry  0  off  the 
application  mentor.  The  child  processes  will  be  located  at 
entries  7.  8  and  9  off  the  application  mentor.  This  scheme 
can  be  better  explained  by  the  diagram  in  Figure  4.3. 


STACK  DATA 


Figure  <4.3  Application  Program  Structure 


The  entries  used  for  this  structure,  were  chosen 
with  no  special  reason.  Other  combinations  could  have  been 
chosen.  The  only  restriction  is  to  position  the  parent 
process  at  entry  0  off  the  application  mentor. 

These  entry  numbers  are  treated  as  paths,  when 
referenced.  So,  entry  7  off  entry  5  off  the  system  mentor, 
is  called  5,7.  This  will  be  used  in  the  file  with  the 
commands  for  the  sysgening  phase.  Those  entries  have  to  be 
passed  as  parameters  during  the  creation  and  makeknown  of 
segments . 

For  the  application  program  developed,  a  segment  for 
the  'purpose  of  executing  the  synchronization  was  created , 
and  will  be  located  at  entry  6  off  the  application  mentor. 

4 .  Process  Synchronization 

Process  synchronization  is  accomplished  using  the 
eventcount  of  the  synchronization  segment  (5,6;,  and  the 
eventcount  of  the  stack  segment  of  each  child.  Advancing 
each  eventcount  in  turn,  the  parent  process  would  prepare 
each  child  to  execute  its  code,  as  soon  as  the  parent  makes 
an  AWAIT  call.  The  child,  would  then,  after  execution, 
advance  the  eventcount  of  the  syncronization  segment,  which 
is  the  one  being  read  by  the  parent  process.  This  scheme 
would  be  repeated  and  the  synchronization  between  all 
processes  is  achieved.  The  actual  sequence  of 


synchronization  used  in  the  programs  developed,  can  be  seen 


C.  GENERATION  OF  A  SECURE  PROGRAM 

To  prepare  programs  to  run  in  the  Gemini  Secure 
Operating  System  iGEMSGS)  environment  is  mucfi  more 
complioated  than  running  a  Janus/Ada  program  in  a  non-secure 
environment.  There  are  some  specific  calls  the  program  has 
to  make,  in  order  to  be  recognized  by  the  GEMSOS,  and  gain 
access  to  the  security  kernel.  The  programs  are  compiled 
and  linked  like  normal  Janus/Ada  programs.  The  command 
(CMD)  files,  will  then  be  put  in  the  secure  environment.  To 
assign  the  security  classification  and  prepare  the  programs 
to  run  in  a  secure  environment,  a  secure  volume  must  be 

created  by  running  the  operating  system  generation  program 

*  ■  • 

(SYSGEN).  Execution  of  the  SYSGEN  program  will  include  the 
application  programs  into  a  segment  structure,  which  will 
then  be  transformed  into  a  bootable  executable  program. 

The  SYSGEN  program  reads  a  submit  file  to  identify  the 


segment  structure. 


This  submit  file,  for  the  current 


implementation,  will  have  the  format  as  in  Figure  4.4. 

Except  for  the  application.cmd  and  the  child.cmd  files, 
all  the  other  segments  are  to  be  sysgened  exactly  as 
described  in  Figure  4.4.  The  submit  file  used  to  SYSGEN  the 


application  program  implemented  is  listed  in  Appendix  E  . 


File  :  Application . ssb 

bs : ld3 . cmd 

ks : kO . cmd 

ks : kl . cmd 

ks : kOh . cmd 

ks : k2 . cmd 

cs : vlloader . cmd ; 2 ; 

ds : vl login . cmd ; 2 , 10 ; 

ds : nv . ds ; 2 , 5 ; 

ds : nv . dS ; 5 ; 

ds : application . cmd ; 5 , 0 ; 
ds : childi . cmd ; 5 , 7 ; 
ds : Child2 . cmd ; 5 , 8 ; 


ds : rltrap . cmd ; 6 ; 
end  • 


Figure  4.4  Submit  File 


D.  LOSS  IN  PERFORMANCE 

In  order  to  achieve  a  secure  environment,  we  have 
developed  our  program  using  four  different  processes,  which 
can  have  different  access  classes.  During  the  execution  of 
the  secure  program,  the  operating  system  will  perform 
security  checks  each  time  a  process  is  brought  into 
execution  and  each  time  a  segment  is  accessed.  Evidently, 
some  overhead,  in  comparison  with  a  non-secure  system, 
exists.  A  test  program  was  developed  in  order  to  extract 


the  preliminary  measurements  of  such  a  overhead. 


The  same  structure  used  in  the  application  process 
developed,  was  used  in  this  test  program. 

The  algorithm  used  in  the  main  program  is  described 
in  Figure  4.5. 


Package  body  TGTIME  is 
begin 

perform  initialization 
create  parent  segment 
create  synchronization  segment 
create  processes 
case 

•  execute  calculations  with  no  calls 

execute  calculations  with  one  call 

execute  calculations  with  calls 

every  loop 

end  case 
delete  processes 
end  TOTIME; 


Figure  4.5  Package  TIME 


When  the  procedure  to  execute  calculations  with  no 
calls  is  activated,  the  program  will  perform  a  simple 
arithmetic  calculation  30000  times.  These  calculations  will 
be  performed  by  the  main  process,  after  the  creation  of  all 
child  processes,  and  with  values  already  in  the  main 
process,  so  there,  are  no  GEMSOS  calls. 


When  che  procedure  to  perform  calculations  with  one 
call  is  activated,  the  program  will  activate  two  processes: 
CALCl  and  STODISP.  The  STODISP  process  will  supply  one 
value  to  the  CALCl  process .  CALCl  process  will  receive  tnis 
value  and  perform  the  same  arithmetic  calculation  as  before 
30000  times  as  well.  The  actual  value  passed  by  one  process 
to  the  other  is  irrelevant,  and  it  is  there  just  to  provoke 
a  call  to  the  operating  system  during  the  transmission  of 
the  value.  The  result  of  the  calculation  will  be  displayed 
by  the  STODISP  process . 

Finally,  the  procedure  to  perform  calculations  with 
call-'  in  every  loop  is  activated.  The  program  will  then 
activate  CALC2  and  STODISP  processes.  Process  CALC2  will 
perform  the  same  calculations  as  before,  but  this  time  will 
include  in  every  loop  of  the  computation,  a  transmission  of 
data  between  the  STODISP  and  CALC2  segments . 

Because  a  loop  statement  is  being  used  to  control 
these  tests,  two  measurements  are  taken  at  the  first  step 
(calculations  with  no  GEMSOS  calls),  in  order  to  estimate 
the  contribution  of  the  loop  control  code  to  the  overall 
time  taken  by  the  calculation. 

All  those  steps  are  measured  and  analysed. 

2 .  Performance  Results 

The  results  obtained  from  the  test  program  are  the 
following : 

1)  With  no  GEMSOS  calls,  30000  operations  =>  3.33 

seconds . 


2)  with  four  14)  GEMSOfc  calls .  30000  operations  =  ■■  3,28 

seconds . 

3)  With  four  i 4)  GEMSOS  calls  for  each  operation,  300 
operations  =>  23.8  seconds. 

At  the  first  step,  no  GEMSOS  calls,  another 
measurement  was  taken,  doubling  the  number  of  operations  and 
maintaining  the  same  loop  number,  in  order  to  estimate  the 
time  delay  contribution  of  the  loop  control.  The  time 
measured  was  6.03  seconds,  which  shows  that  the  actual 
operations  take  2.7  seconds,  and  the  loop  control  is 
responsible  for  0.63  seconds.  Since  we  execute  the  loop 
30000  times,  it  is  possible  to  estimate  the  time  delay  for 
each.;  loop  to  be  21  useconds.  The  times  measured  show  that 
each  mult/div  operation,  which  there  are  12  on  each  loop,  is 
using  7.5  useconds,  which  is  the  expectable  time  delay  for  a 
APX-286  CPU . 

The  time  measured  during  the  execution  of  the  second 
step,  the  same  number  of  operations  plus  four  GEMSOS  calls, 
did  not  show  any  appreciable  difference. 

At  the  third  step,  where  there  are  four  GEMSOS  calls 
on  each  loop,  and  the  loop  is  executed  300  times,  the  time 
measured  was  23.8  seconds.  As  the  test  executes  the  loop 
300  times,  each  loop  uses  79  milliseconds.  Assuming  the 
same  loop  delay  time  as  before,  each  loop  control  uses  21 
useconds,  and  the  time  delay  of  the  actual  calculations  is 
(12  x  7.5  useconds)  90  useconds.  Therefore,  as  four  GEMSOS 


calls  are  executed  in  each  loop,  each  call  uses  an  average 
of  19  milliseconds . 

These  preliminary  measurements  are  far  from 
complete,  but  the  results  obtained  can  be  considered  as  a 
design  parameter  to  be  expected  when  the  security 
environment  is  used  with  the  Gemini  system. 


V.  APPRECIATION  OF  RESULTS 

A.  GENERAL  COMMENTS 

The  development  of  application  programs  to  execute  in 
the  Gemini  microcomputer  proved  to  be  much  more  time 
consuming  that  it  was  anticipated.  Testing  and  debugging  of 
the  programs  could  not  be  done  using  the  techniques  and 
skills  normally  used  when  working  with  non-secure  systems. 
Some  factors  can  be  listed  as  the  major  ones  which 
contributed  to  this  problem.  They  were: 

1 )  new  terms  and  concepts  that  had  to  be  completely 
understood  before  attempting  to  use  the  system 

2)  preliminary  version  of  the  manuals  provided,  which  are 
still  being  updated  and  developed 

3;  preliminary  version  of  the  library  programs  which  do 
not  include  yet,  most  of  the  common  needed  procedures 

4)  the  system  used  was  configured  with  two  floppy  disk 
drives . 

The  Janus/Ada  gate  calls  for  the  Gemini  Secure  Operating 
System  (GEMSOS) ,  are  not  yet  very  well  explained  in  the 
manuals  provided.  As  such,  any  time  a  new  call  was  to  be 
tested,  in  order  to  increase  our  understanding  of  a  new 
concept,  the  complete  process  of  preparation  of  a  program  to 
run  in  a  secure  environment  had  to  be  executed.  Since  this 
process  involves  the  access  to  a  large  number  of  files,  the 
fact  that  the  system  used  floppy  disk  drives,  imposed  a  time 
delay  of  at  least  7  minutes. 


As  discussed  in  Chapter  III,  in  order  to  prepare  a 
program  to  run  in  the  secure  environment,  the  operating 
system  generation  program  (3YSGEN)  had  to  be  executed,  wnicn 
would  create  a  secure  volume  containing  the  program  segment. 
Before  running  the  system  generation  program,  the 
application  program  had  to  be  compiled  and  linked  in  the 
normal  way. 

After  the  creation  of  the  secure  volume,  the  system  has 
to  be  reinitialized  with  the  secure  application  program 
volume.  If  a  problem  is  found  in  the  execution  of  the 
program,  the  system  will  either  execute  an  interrupt  trap 
halt-7  indicating  the  processor’s  register  contents,  cr 
sometimes  will  halt  completely  not  giving  any  indication  on 
the  screen.  The  error  then,  must  be  corrected  before  any 
further  progress  can  be  achieved.  After  the  correction  has 
been  made.  the  preparation  process  has  to  be  repeatea 
completely  to  check  if  the  modification  was  successful.  The 
average  amount  of  time  from  compilation  to  the  final  run  of 
a  program,  was  found  to  be  between  15  to  17  minutes  for  the 
application  programs  developed  in  this  research. 

The  use  of  the  modular  programming  technique  is  very 
important  for  the  compilation  and  linking  phases,  but  as  the 
preparation  of  the  secure  program  has  the  "sysgening"  phase, 
where  all  the  modules  have  to  be  included,  the  modularity 
does  not  bring  great  advantages  to  the  preparation  phase. 
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Improved  versions  of  the  Gemini  system  will  certainly 
become  available  in  the  near  future,  which  will  reduce 


significantly  the  effects  of  these  problems.  System 
libraries  will  be  expanded,  making  the  process  of  writing 
programs  to  be  run  in  the  secure  system  less  complicated  and 
time  consuming. 

B.  SYSTEM  OPERATION 

The  system  designed  proved  the  possibility  of  using  a 
secure  computer  system  as  the  main  building  block  in  a 
tactical  computer  system.  The  ability  of  handling  different 
and  somewhat  independent,  processes,  easily  synchronized  by 
the  calls  already  provided  by  the  operating  system,  was 
demonstrated  by  the  model  implemented.  The  actual  code  of 
the  modules  used  do  not  represent  any  real  application,  but 
only  exemplifies  that  they  can  be  independently  developed, 
and  integrated  into  a  complete  system. 

Due  to  the  problems  already  discussed  in  the  previous 
sections,  the  amount  of  time  for  this  research,  was  not 
sufficient  to  proceed  with  the  next  step  scheduled,  which 
was,  to  label  one  of  the  processes  as  secret  and  then  limit 
the  access  based  on  the  security  level  of  the  operator 
logged  on  the  system. 

The  use  of  the  system  clock  to  control  the 
synchronization  between  the  different  processes  involved  in 
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the  application  program  could  not  be  completed  in  time  to  be 


included  in  this  thesis. 

The  overhead  analysed  has  shown  that  an  average  of  19 
miliseconds  is  used  for  each  GEMSOS  call,  where 
synchronization  and  security  checks  are  performed.  This 
time  delay  has  to  be  taken  into  account  when  the  tactical 
system  is  designed,  but  certainly  it  is  not  a  high  price  to 
pay  in  order  to  be  able  to  develop  a  system  with  a  large 
number  of  security  possibilities  available. 

C.  CONCLUSIONS  AND  SUGGESTIONS 

In  this  thesis,  a  model  of  a  tactical  combat  system  was 
developed  to  demonstrate  the  possibility  of  using  a 
multilevel  secure  computer  system  in  this  environment.  The 
Gemini  Trusted  Multiple  Microcomputer  Base  used  in  this 
research,  proved  to  be  able  to  synchronize  the  execution  of 
independent  processes  which  will  give  the  capability  of 
assigning  different  security  labels  to  these  processes. 

Although  it  has  not  been  possible  to  achieve  all  the 
desired  goals  proposed  when  this  thesis  was  first  planned, 
the  concepts  and  research  done,  will  certainly  facilitate 
any  further  work  to  be  done  in  this  new  area. 

Most  of  this  research  was  done  in  conjunction  with 
another  student.  Major  Miguel  Reyes,  working  with  the  same 
microcomputer,  which  to  a  certain  extent  guarantees  that  the 


results  here  obtained  are  completely  Known  by  a  follow-up 
researcher . 

The  unit  testing  of  application  program  modules  should 
first  be  accomplished  on  development  systems  which  nave 
existing  tools  for  testing  the  logical  correctness  and  real 
time  performance.  A  specially  trained  ’’lead  programmer" 
should  take  the  unit  tested  modules  and  incorporate  these 
into  a  system’s  program  'which  synchronizes  the  units  and 
produces  the  necessary  communications  between  the  units  in  a 
secure  systems  environment.  The  art  of  systems  integration 
programming  in  a  secure  environment  requires  an  in-depth 
understanding  of  GEMSOS  functions  as  well  as  the  real-time 
performance  of  the  system. 


APPENDIX  A 


APPLICATION  PROGRAM  LISTING 


This  application  program  is  compiled  and  prepared  for 
execution  in  the  manner  discussed  in  Chapter  III.  The 
program  consists  of  four  packages,  each  one  generating  a 
separate  command  iCMD)  file.  The  packages  to  be  sysgened  as 
child  processes  are  designed  to  have  procedures  which  can  be 
altered  without  modifying  the  overall  synchronization  of  the 
application  program. 


This  package  controls  the  operation  of  the  complete  — 
system 


with  arl,  alib.l,  agate,  manag,  tables,  gemio,  alib,  crprcce: 
package  body  TERRAIN  is 

use  arl,  alibj,  agate,  mar.ag,  tables,  gemio,  alib,  crproce; 

—  constants 

STCIO  V  :  CONSTANT  integer  :=  i; 

STDIO’R  :  CONSTANT  integer  :=  0? 

IO_?ORT  :  CONSTANT  integer  :=  0J  —  0  port  for  main  program 

—  variables 

ini  t 
calls 
ch_tatle 
ch_level 
seg^mode 
ch_tab 
ch_lev 
w_cla  ss 
class 
rd_class 
in~choice 
pass_rad 
pass_chaf 
mentor 
entry* 
def  seg 
def "of f 
def "size 
size 
success 
seg_number 
synchr_seg 
choice" 
evc_value 

procedure  INITIALIZATION  is 
begin 

—  attach  serial  port  for  writing 

at tach_ tew  (IO_FORT,  STDIO.W); 


rl_process_4ef ;  — necessary  for  all  kernel 

rl_parami 

usir_level ; 

seg_acres  s_type ; 

rl_parameters» 

level_record ; 

access_class ; 

access_class? 

accesslclass. 

string; 

radar_input  J 

chaf f_out ; 

in  teger 5 

integer; 

integer; 

integer; 

integer; 

integer; 

integer ; 

integer! 

integer; 

integer; 


attach  serial  port  for  reading 


at tach_ter  'IO_?ORT,  S'rEIO_P.;; 

—  load  parameters  to  create  up  to  4  children 

1  oad_parair_  t o_4_chld  ( ini  t ,  ch_  table  )  * 

— load  access  classes  for  Top-Secret,  Secret,  Confidential 
and  Unclassified  . 

load_access_class  (ir.it,  ch_level); 

—  prepare  class  for  accessing  main  terminal 

w_class  :=  i^it. resources. min_class* 
end  INITIALIZATION; 
procedure  STACK_AND_SYNC_CREATIQN  is 
begin 

—  creating  segrent  for  s tack(parent 1 .Will  be  unclassified 

—  so  as  to  obey  compatibility  property  :  segment  compromise 

—  must  dominate  mentor  compromise. 

mentor  :=  ini t . in i tial_seg( 2 ) ; 
entryx  : =  *; 

class  ir.  it .  resources  .min  _class; 
size  :=  128 ; 

cr_segmen  t (init,mentor, entryx , si ze, class, success); 
if  success  /=  0  then 

put_succ ( "succe ss  stack  parent  ” , succ ess , w_class ) ; 
put_ln  (STDIO_W,w  class,"’); 
end  if? 

—  makeknown  this  segment 

seg_mode  :=  r_w; 
seg_number  •=  21* 

mk_segment( init, mentor, entryx, 

seg_number, seg_mode  ,  success  ' ; 

if  success  /=  0  then 

put_succ (" succe ss  makeknown 

stack  parent" , success ,  class); 
put_lr.  (STDIOJ*  ,w_class,"  *); 


end  if; 


—  creating  synchronization  segment  .  Will  te  Tcp-Secret. 

mentor  :=  ini t . i ni tial _s eg{ 2 ) ; 
entryx  :=  6; 

class  :=  init. resources .min_class; 

cr _segmen  t ( init.mertor , en tryx  , size, class, success); 

if  success  /  =  ?  then 

put_succ( "success  sync  i^"  .success  ,w_class  ) ; 
put”ln(STDIO  V,w  class,"’); 
end  if; 

—  makeknovn  this  segment 

seg_mode  :=  r_w? 
seg_numher  :=  51» 

mk_segmen  t ( ini t ,mer  tor ,en tryx , seg_numter , seg_mode .success ) ; 
if  success  /-  Z  then 

put  succ( "success  mkknown  sync” .success ,w  class); 
uut~ln ( STS- 10  W.w  class,'”’); 
end  if; 

synchr_seg  :=  seg_nunrter» 

—  swapin  this  segment 

swapin_segmen t ( seg_numter .success) 5 
if  success  /=  0  then 

put_sucr  ( ’’succe  ss  swapin  sync’  ,  succes  s  ,  w_c  1  as  s  ) ; 
put_ln(STDIO  V.w  class,””)! 
end  if; 


end  STACX_AND_SYNC_CRSATI0N: 
procedure  PR0CPS S_CREATICN  is 
begin 

put_l n ( STDI0_W ,v_cla ss , "Begin  Process  Creation"); 
typi_any _key_to_c ont inue ( w_class ) ; 

—  start  creating  processes  in  the  system 

—  process  1  ==  >  Radar 

—  process  2  ==  N  Compute 

—  process  3  - -  >  Chaff 
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—  all  processes  with  unclassified  acess  class 

—  next  version  to  have  process  2  changed  to  Top-Secret 
order 

tc  access  Secret  data. 


for  i  in  1 . .3  1 oop 


ch_tab  :=  ch_tafcle(i); 
ch  lev  :=  ch2level(4); 


end 


to_create_process(init,ch_tat, 

ch_lev7i,synchr_seg, success) 


loop; 


end  PROCESS  CREATION  ; 


procedure  MENU  (selection  :  out  integer)  is 

—  Present  optior  to  run  tactical  program  or  alter  d 
field 

—  Data  field  to  secret  in  next  version 
begin 

put_ln  ( STDIQJt’ ,v_cla  $s  ,  "^un  Tactical 

Program  ==  >  <"  any  key  >" ) ; 
put  ln(STCI0  V,v  class, "Alter 

Data  Field  *■  >  <  A  >”); 

put  ln(STDIO  W,v  class, "Exit  Program 

=  -  >  <  e  >”); 

get_str  ( STD IO_RJ{rd_c lass  ,in_chcice ) ;  m 
if  In_choice  =  a”~or  in_choice  =  "a”  then 
ielection  :*  l; 

elsif  ir'_choice  *  "e"  or  in  choice  =  "s"  then 
selection  :=  2? 

else 

selectic"  : =  35 
end  if; 


end  PFNU; 

procedure  ALTER  is 
begin 

put_ln ( STDIO_W , w_cla ss , "Not  implemented  yet"); 
end  ALTER; 


procedure  RFCEIVF  FP  RADAR  is 


begin 

def_seg  := 

lit  jrlc_sel  (ldt_table,ch_tatle(l) .  seg_nurrber_data  ) ; 
def_off  :=  0; 

def  size  :=  radar_inpu t 'si ze  /S» 
movi_tytes  def  _seg,def  _cf  f  , get_ss( ) , 

pass^rad 'ADDRESS ,  de  f_s i ze } ; 


end  RECEIVE_FM_RADAR  ; 
procedure  ?ASS_TO_COMPUTT  is 
begin 

def_seg  : = 

lit  mk  sel(ldt  table, ch  table(2)  .seg_nurrter_iata)  ; 
def  off':=  0? 

def”size  :=  radar_input. 'si  ze  /SJ 
move_bytes 

(get_ss(),pass_rad ' ADDRFS  S , def _seg ,def _of f,def_size)I 
er.d  PAS S_T0_ COMPUTE  ; 
procedure  R£CFIV7._FM_C0MPUTF  is 
begin 

def_seg:=lit_mk_sel( lxdt_table , 

ch  txatle(2) . segx  number  date)x; 

def  off  :=  0; 

def_size  :■=  chaf  f_out ' s i  ze  /S', 

move_bytes ( def_seg,def_off,get_ss(  ),  pass_chaf  'ADDRESS 

,def_size)I 

end  RECIIVE_FM_COKPUTE  * 
procedure  ?ASS_T0_CFAFF  is 
begin 

def_seg  := 

lib  T«k  sel(ldt  table, ch  tatle(3)  .  seg_numbe r_da ta  5 
def _of f  :=  *7 

def’size  :=  chaff  out'size  /S; 
rrove_bytes'get_ssT)fpass_chaf 'ADDRESS, 

def_seg, def_off ,def_size ) ; 

end  PASS_TO^CHAFF? 


procedure  RUN  is 


begin 


$ 

i 


pass_rad . flag_2  :=  false; 
outer  :  loop 

inner  :  for  i  in  1..3  loop 

advance(ch_table(i ) .seg_number_stack, success)  ; 

read_evc ( synch r_seg , eve _ value .success ) 5 
await ( synchr  seg.evc  value+1 .success) i 
if  i  =  1  then 

receive_fm_radar! 
if  pass_rad . flag_2  then 
exit  outer, 
end  if; 

pass_to_compute; 
elsif  i  =  ~2  then 

receive_fm_compute  ; 
pass  to  chaff; 
end  if;  " 
end  loop  inner; 
end  loop  outer; 


end  RUN? 

procedure  SELE_DELET ION  is 


begin 


for 


end 


i  in  1 .  .?  loop 

advance (ch_t a ble( i ) . seg_numter_s tack, success ) ; 
read  eve ( synchr_seg .eve  value , success ) ; 
await ( synchr_seg,evc_value+l .success) J 
loop; 


end  sriF_ETirT ION ; 

procedure  BELETE_F?OCESS_SEGMENT  is 


begin 

for 


i 


in  1 . .3  loop 

child_delete( i-1 ,  success); 
terminate  segmert{ch_table(i).seg_number_s tack, success) ; 
terrrinate“segirent(ch_table(  i  )  . seg"number_ia  ta  ,  succe  ss)  ; 
terninate_segrent(ch_table( i) .  seg_number_code , success ) ; 
delete_segment( ch_ table ( i).mertor_stack,i, success;; 
dele  te^segme  nt  ( ch~table(i). me ntor_data,i+4,  success), 
delete "segment  (rh_table(i) .men  tor_code,i +6, success) ; 
end  loop; 


end  DELETE  PROCESS  SEGMENT; 
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procedure  DELFT£_^ENTO?._SYNC  is 
begi  n 

ielete_segment  (  init  .1  ni  tial_seg(2  ) ,  ,  success); 

terminate  segment  (51,  success); 

del  et  e_segm  en  t  ( init  ,ir.i  tial_seg  (2  ) ,  5,  success^; 
terminate_segment  (31  .success); 


end  DELETE  MENTOR  SYNC  ? 


procedure  DELFTION_ALL  is 
begin 

self_deleti on? 
delete  process.segment ? 
delete "men  t  or_sync ; 

end  DELETION _ALL  ? 

procedure  PR£VENT_TRAP  is 

begin 

success  :  =  0? 
while  success  =  0  loop 
success  :=  0? 
end  loop? 

end  PREVENT_TRAP  ? 

—  ############*  MAIN  PROGRAM  ############## 

begin 

init  : =  get  rl_def ( )  ? 

lib  set .bracket ( 1 , 1,1, init .resources .min_c lass ) ? 

initialization? 

stack_ar.d_sync_creation? 

pr ccess_creation  ? 

loop 

menu (choice ) ? 
case  choice  is 

when  1  =>  alter  ? 
when  2  ->  EXIT? 
when  3  ~>  run? 
end  case? 
end  loop? 
deletion  all? 
prevent  trap? 
end  THIMAIN  ; 


—  This  package  simulates 
radar,  as  an  input  to  a 

the  sampling  of  a 
tactical  system 

tracker 

— 

with  arl,  manag,  gemio, 
alitj  ; 

package  tody  RADAR  is 

s  t  r  1  i  t , 

agate  , 

tatles  , 

alit 

use  arl,  manag,  gemio, 
alitj; 

strlit, 

agate  , 

tables  , 

alit 

—  constants 


STDIO  W  : 

CONSTANT  integer  := 

i; 

STDIO'R  : 

CONSTANT  integer  := 

0; 

10  FORT  : 

CONSTANT  integer  := 

s; 

I NIT  DIST 

:  CONSTANT  integer 

:=  10030 

INIT~5EAR 

:  CONSTANT  integer 

:=  090; 

CR 

:  CONSTANT  integer 

:=  13; 

—  variables 

ini  t 

:  rl_process_def ; 

v_class 

:  access_class ; 

mlss_rec 

:  radar_Irput; 

success 

:  integer; 

evc_ch_val 

:  integer; 

def  seg 

:  integer? 

def "of  f 

:  integer? 

def _size 

:  integer; 

procedure  GET_TRACK  is 

—  simulate  tracking  of  a  missile 

—  constants 


tegi  n 

miss_rec  .radarl  miss_rec  .radarl  -  50! 
if  mlss_rec . radar  1  <  2000  then 

miis_rec . rada r2  :=  mi ss_rec .radar2  -  1» 
end  if; 

put  _str  ( STDIO_V»' ,  v_cl  as  s  ,  RANGE  ); 
put2dec(STDI0_>/  ,w_c lass,  miss_rec. radarl); 
put~str ( STDI0~W ,w~clas s  ,  "  BEARING  "  ) ; 
put "dec (STD 10 ~W ,w "class ,mi ss_rec .radar2) ; 
put^str(  STDIGJa  ,v~class  , char” to_str( character  'val  (CP.) ) 
if  miss_rec. radarl  <  600  then 
miss  rec.flag  z  :=  true; 
end  if; 


end  GFT_TRACr; 

procedure  PA£S_TO_FARENT  is 

begin 

def  seg  :=  lit  mk  sel(ldt  table  .init  .initial  seg(3))i 

def^off  :=  05  ” 

def_size  :=  radar  input'size  /65 

movi_by  tes  (get_ss[),miss_re''  'ADDRESS  ,def_seg,cef_off  ,def_size 
end  PASS_TO_FARTNT  5 
—  MA IN  PROGRAM 


tegin 

init  :=  get _rl _def ( ) 5 

—  attach  terminal  to  write 

at  t ach_ t ew  f I0_F0RT ,STDI0_V ) 5 
w_cla  ss  ■=  init. res ourres.min_class5 

—  attach  terminal  to  read 

attach_ter( I0_P0RT , STD IC_R )  5 
put_ln(STDIOJ»,w_class,"  RADAR  ")5 

—  Advance  the  eventcount  of  the  synchronization  segment 

—  path  5,6  ,  pi sr  51  ,  passed  to  child  as  ch  seg_l is t ( 2 ) . 

—  Will  te  recognized  in  child  as  init. initial_seg(2)  . 


ad  van ce ( i ni t . i ni t ial _seg( 2 ) , succes s ) 5  —  this  will 

permit’creation  of  processes  to  go  or 

read_evc ( in i t . ini t ial_seg( 0 ) ,  evc_ch_val , suecess)?-- 
stack  to  sync 

await ( init . ini tial_seg (0 ) , evc_ch_val+l .success ) 5 
control  sent  tack’to  creation  of  processes. 

mi ss_rec . f 1 ag_z  :=  false? 
miss_rer .radarl  :=  INIT_DIST5 
mi  ss”rec  .  radar2  :=  I N I T  ~  3Z  A.R  t 

loop 

get_track5  —  get  track  information 

pass_to_parent5 

advanceTin i t . in i t ial  seg(2)  .success)  5 
read_evc ( i ni t . i ni tial_seg(0 ) , evc_ch_val .success ) 5 
await'init.initial_segl'C),evc_ch”var+l  .success  )5 
if  mi ss_rec . f lag_z  then 
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niss_rec  .rad  arl  :=  INIT_DISTJ 
mi ss_rec . rada r2  :=  INIT_3EAR? 
end  if? 

end  loop; 

adv  an  cei'init.initial_seg(2), success);. 

—  detach  and  deletion 

detach_device(STDIO_R,success); 
det ach_devi ~e (  STD  1 0_W,  success)  ; 
self _delete(init.initial_se^ (2),  success) 


end  RADAR? 


This  package  performs  the  actual  computations 


with  arl,  manag,  gemio,  strlit,  agate,  tables,  alit,  alitj; 
package  body  COMPUTE  is 

use  arl,  manag,  gemio,  strlib,  agate,  tables,  alit,  alitj; 


constants 


STDIO  W  :  CONSTANT  integer  :=  l; 
STDIO’P.  :  CONSTANT  integer  :=  05 
IO_PORT  :  CONSTANT  integer  :=  3? 
CR"  :  CONSTANT  integer  :=  13; 

—  variables 


init 
w_class 
rad_i r 
cha_out 
ship_rec 
def  .seg 
def ~ of f 
def _si ze 
success 
eve  ch  val 


rl _process_def ; 
access_class; 
radar_Input 5 
chaf f _out ; 
ship_param; 
integer; 
integer? 
in  teger; 
integer  5 
integer? 


procedure  RFCEIVF_FM_PARENT  is 
begin 

def  seg  :=  lib  mk  sel( Id t_table  ,  ini t  .ini t ial_seg( 3) ) ; 
def'off  :=  2? 

def~size  :=  radar_input ' si ze  /8J 
movi_ty tes ( def_seg,def_off, 

get_ss(),rad_ir 'ADDRESS ,def _si ze  ) ; 


end  RKFIVF_F^_PARFNT; 
procedure  PASS _T0_PARENT  is 
tegi  n 

def  seg  :=  lit  mk  se  1  ( Id  t_tatle ,  init. initial  seg(3M? 
def "off  :=  0; 

def’size  :=  chaff  out'size  /S » 
move  tytes(get  ssO.cha  out'ADDRFSS, 

def _seg,def _of f ,def _si ze ) ; 


end  PAS3_T0_PARFNT  ; 
procedure  CALCULATION  is 


put_strCSTDIO_V,w_class ,  Computing  ...  ); 

put_It  r(  STD  I0_W  ,w_class  ,char_tb_str  ( character  'val  (CP. ))) 
cha_out . chaff  1  :  = 

( ( rad_in  .radarl/100Z)s:!ship_rec.paraml)+?5; 
cha_out .  cha  f  f  2  :=~(  rad  _ir. .  radar2/l?  )  +  -30; 

end  CALCULATION  ; 


—  MAIN  FROGRAM 


begin 

ship_rec . paraml  :=  2* 
init  :=  get_rl_def ( ) ; 

—  attach  terminal  to  write 

attach_tev  ( IO_PO?.T  ,STBIO_V  ); 
v_class  :=  in i t . res ources . min_nlass 5 

— attach  terminal  to  read 

attach_ter( I0_P0RT , STD  10 _R ) 5 

put_ln(STBIC_V,v_class , "  C  0  M  P  U  T  7 

—  advance  eventcount  of  synchro  segment  path  5,6  plsn  51 

—  passed  to  child  as  rh  seg_list(2). 

—  Will  he  called  in  child  as  init .  in  it ial_segf 2 ) 

advance  ( in i t . ini tial_seg( 2 ), success ) ; 

re ad _evc(init. initial _s eg (0),evc_ch_val, success); 

await(init. iritial_seg(0) ,evc_ch_val+l,success>; 

cha_out .f lag_z  :=  false; 

loop 

receive_fm_parent ; 
calculati on ; 

if  rad _ in  .  rada rl  <  1500  then 

put  ln(STDIO  W , w  class,"’’); 
put~str ( STUIO  W , w  class,”  7  I  R  7  "  ,  J 
end  if; 

pass_to  parent; 

advaiiceTinit  ,initial_seg(2)  .success); 
read_evc( init . ini tial_seg(0 ), eve  ch  val .success) ; 
awaitdnit.  ini t ial _seg(0; ,evc_ch“var+l  .success ) ; 
end  loop; 


s 


advance ( ini t . initial _seg( 2 ) .success)? 

—  dettach  and  delete 

detach_device(STDIO_R,  success)? 

de tach'devi ce ( STDIO  W, success)? 

self  delete{ init .inftial_seg(2 ) ,  success)? 


end  COMPUTE  ? 
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This  package  simulates  the  driving  of  a  weapon  device  — 


with  arl,  manag,  gemio,  agate  .strlib,  tables,  alih,  alibj  ; 
package  tody  CHAFF  is 

use  arl,  manag,  gemio,  agate  ,strlit,  tables,  alib,  alitj  ; 


•constants 


STDIO  V 
5TDI0~R 
10  "PORT 

cr" 


—  variables 

init 
w_class 
cha_con  t 
def  seg 
def "of f 
def "size 
success 
eve  ch  val 


CONSTANT  integer  :=  1? 
CONSTANT  integer  :=  05 
CONSTANT  integer  :=  55 
CONSTANT  integer  :=  13 ; 


r l_process_d  ef ; 
access_class ' 
chaf f _out ; 
i  ntegir; 
integer ; 
integer i 
integer? 
integer? 


procedure  RICE IVE_FM_PARENT  is 
begin 

def  seg  lib  mk  sel(ldt  table , ini t .  ini tial  seg(3)); 
def “of f  :=  0;  “ 
def~size  :=  chaf f _out ' si ze  /8J 
rrove_bytes(def_seg,def_off,get_ss(), 

cha_cor.t 'ADDRESS  , def  _si  ze) ; 

end  RFCEIVE_FM_PARENT  ; 

—  MAIN  PROGRAM 
begin 

init  :=  get_rl_def ( ) ; 

—  attach  terminal  to  write 

attach, tew (IC_PORT, STD IO_W); 
w_clasl  :=  inf t . resource s.min_class; 

— attach  terminal  to  read 

attach  ter(IO  PORT,STDIO  R); 

put _lnrSTDIO_W,w_c lass, ”"C  RAFF  "); 


—  advance  eventcount  of  sync  segment  path  5,6  plsn  51 

—  passed  to  child  as  ch_seg_list (2 ) . 

—  Will  he  called  in  child  ai  ir it . ir it ial_seg( 2 ) 

advance  ( in i t .  i ni t  ia  1  seg(2  success  ) ; 

read_ev c(init. initial's  eg (0), eve _ch_val  .success); 

await(init.initial_seg(0) , evc_ch_val+l  .success ) * 

cha_cont . flag_z  :=  false; 

loop 

receive  fm  parent; 

put_strISTEIO_W,w_class,”  BEARING  "); 
put~dec( STDI0~V ,w "class, c ha  cont.chaf fl) ; 
put~str(STDIO  J»  .w^class . "  ‘  ELEVATION’'); 

pu t ”de c { STD I0~V, v”c la s s,cha_c on t . chaff 2  ) ; 
put_str(STEIO_Vi',w  class, char_to  str( character 'val  (  CR)  ) ) 
advance( init . init ial_segl2 )  ,  success); 
read_evc (in  it. initial_seg(0)*evc_ch_val, success) 
await ( init . i ni t ial_seg(? ) , evc_ch”val+l .success ) ; 
if  cha_cont . flag_2  then  ” 

put_ln ( STDIO_W  ,w_class  ,”" ) ; 
put_ln( STDI0_W ,w_class  ,”  PARKED  " ) ; 
cha~cont .f lag  2  7=  false; 
end  if; 
end  loop? 

put  1  n(STEI0  W,w  class,'’"); 

put”ln  ( STEIO~V  ,w”cla  ss  ,  ’’  PARKED  ’’ ) ; 

ad vance(init. initial's  eg (2) .success) ; 

—  dettach  and  delete 

detach_device(STDIO_R, success); 
detach~device(5TDI0_V, success); 
sel f_delete (init. inltial_seg(2), success); 


end  CHAFE  ; 


APPENDIX  B 

LIBRARY  PROGRAMS  LISTING 

These  packages  were  built  in  order  to  concentrate  all 
common  procedures  used  for  the  application  program  developed 
in  this  research.  They  are  far  from  complete,  although  they 
establish  the  organization  necessary  to  develop  secure 
applications  programs.  Some  of  the  procedures  included  in 
this  library  were  taken  from  the  demonstration  program 
supplied  by  the  manufacturers  of  the  Gemini  computer. 


Specification  for  the  MANAG  package 
Contains  procedures  to  handle  segments 


with  agate,  agatej,  arl,  util; 

package  MANAG  is 

use  agate,  agatej,  arl,  util; 

procedure  CR_SFGMFNT  (init  :  in  rl_process_def ; 

mentor  :  in  integer; 
entrx  :  in  integer; 
size  :  in  integer? 
class  :  in  access_class; 
success:  out  integir  ); 

procedure  MK_SEGMENT  (  init  :  in  rl_process_def ? 

mentor:  in  integer? 
entrx  :  in  integer? 
number  :  in  integer? 
mode  :  in  seg_access_ty pe ; 
success  :  out'i.nteger  ); 


procedure  ATTACE_TSV(  IO_PORT  :  in  integer? 

~LDEV  :  in  integer)? 

—  attach  to  write?  IO_FCRT  is  physical  device  ? 

LDEV  is  logical  device 

procedure  ATTACH_TIR(  IO_PORT  :  in  integer? 

~LDEV  :  in  integer)  ? 

—  attach  to  read?  IO_PORT  is  physical  device 

~LEFV  is  logical  device 

procedure  b24_FRM_INTEGER  (ir_val  :  in  integer? 

b24_val  :  out  b24_type  )? 


end  MANAG? 


This  package  has  procedures  to  handle  segments 
and  terminals 


with 

agate , 

agatej,  arl, 

util  ? 

package  tody 

MANAG  is 

use 

agate , 

agatej,  arl, 

util  ? 

—  Constants  for  device  slots. 


STDI0  W  :  CONSTANT  integer  :=  15 
STDIOJl  :  CONSTANT  integer  :=  0; 

10  FORT  :  CONSTANT  integer  :  =  0?  —  port  zero  for  main 

process 


procedure  CR_SEGMENT (  init  :  in  rl_prccess_def ; 

mentor  :  in  integer? 

entrx  :  in  integer? 

size  :  in  integer? 

class  :  in  access_class ? 

success  :  out  integir  )  is 

—  Create  segment  call 

cr_seg_str  :  create_seg_s truct ? 

begin 

cr_seg_str .ment or  :=  mentor? 
cr~seg~str .entryx  :=  entrx? 
cr~seg_st r  .  1  imi t  :=  size? 
cr_seg~str .class  :=  class? 

crea te_segment (  cr_seg_str,  success  )? 

end  CR  SEGMENT  ? 


procedure  MK  SEGMENT  (  init  :  in  rl_process_def ? 

mentor  :  in  integer? 

entrx  :  in  integer? 

number  :  in  integer? 

mode  :  in  seg_access_type ? 

success  :  out  integer  )  Is 

Makekncvn  segment  call 

seg_rec  :  mk_kn_  s  t rue  t  ? 
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seg_ret_rer  :  mk_kn_return? 
tegin 

seg_rec .rent  or  :=  mentor? 
seg'rec .en tryr  :=  entr*? 
seg^rec . seg_number  :=  number? 
seg^rec . seg^mode  :=  mode; 

seg_rec .prot_level  :=  tyte(  1  )i  — ring  1 

protection 

seg_rec .ga te_number  :=  NULL_INBEX?  — no  gate 

seg^rec .gate'prot  :  =  tyte*1  0  )? 

makekr. own_segmert  (  seg_rec,  seg_ret_rec,  success  ); 
end  MK  SES^ENT? 


procedure  ATTACH_TEV  ( IO_PORT  :  in  integer  ? 

EDEV  :  in  integer)  is 

attach  serial  port  writing 

mode  :  at tach_struc t; 

success  :  integer? 

begin 

mode.dev_name  :=  siow; 

mode .siow_rec ,dev_num  :=  io_port;  — physical  device 
mode .siow~rec .dev^type  :=  io?  — device  itself  to  te 

used 

mode.siow_rec.dev_id  :=  LDEV?  — logical  device 

mode.sicw_rec.rrl  :  =  byte(  15#04D#  );  — device 

conf igurati on 

mode . s i ow_rec .mr2  :  =  tyts(  16#03E#  ); 
mode .s iow“rec .i o_mode  :=  asrt_rts? 
attach_device(  mode,  success  )? 

end  ATTACH  TEW? 


procedure  ATTACH_TER(  IO_PORT  :  in  integer? 

LDEV  :  in  integer)  is 

attach  serial  port  for  reading. 

mode_r  :  attach_struct? 
success  :  integer? 

tegin 

mode_r .dev_nare  :=  sior? 

mode_r . sior_rec ,dev_num  :=  io_port? 


mode_r . sior_rec .dev_type  :=  i o ; 

rrode_r  .sior_rec  .dev_id  :=  LDSV; 

mcde_r . si or_ rec . mrl  :*  byte(  15#04D#  )» 

mode~r.sior3rec.mr2  :=  byte(  16#Z3I#  ); 

mode_r .sicr_rec .io_mcde  :=  asrt_dtr? 

mode  r .sior_rec.delim_active  :=  FALSE; 

mode^r . sior^rec .delimiter  :  =  byte(  13  )» 

mode_r . sior_rec .maximum  :=  1»  —  only  reads  on 

character  at  a  time 

attach_device(  mode_r,  success  ); 
end  ATTACH_TIR; 

procedure  b24_FRM_I NTEGER  (in_val  :  integer? 

b24_val  :  cut  b24_type)  is 

—  to  convert  an  integer  into  a  b24_type  variable  (3  bytes) 
begin 

b24_va 1 .by te2  :=  byte(  e  ) ? 
b24_val .bytel  :=  hi (  in_val  ); 
b24^val .by teZ  :=  lo(  in^val  )5 

end  b24  FRM  INTFGFR? 


end  MANAGJ 
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with  agate,  agatej,  strllb  ; 

package  GEMIO  is 

use  agate,  agatej,  strlib  ; 


procedure 

PUT 

_LN  ( 

ldev 

in 

in  teger* 

w 

_class 

i  n 

access_class ; 

s  tr 

in 

string" ) ; 

procedure 

GET 

_STR  ( 

ldev 

in 

integer? 

r 

_class 

out 

access_class 

s  tr 

out 

string  ); 

procedure 

PUT 

_STR  ( 

Id  ev 

in 

integer; 

V 

_cla  ss 

in 

access_classJ 

str 

in 

string  ); 

procedure 

PUT 

_DEC  { 

Id  ev 

• 

• 

in 

integer? 

w 

_cla  ss 

• 

• 

in 

access_class ; 

dval 

• 

• 

in 

integer  )  5 

procedure 

PUT 

_S’JCC( 

in  str 

• 

• 

in 

String? 

dec  val 

• 

• 

in 

integer? 

V 

_class 

• 

• 

in 

access_class 

procedure  TYFE  ANY  m  TO_CONTINUE  (w  class  :  in 

access  class) 


procedure  3LK_SCR  (  ldev  :  in  integer? 

w  class  :  in  access  class); 


end  GEMIO ; 


This  package  contains  procedure  to  handle  I/O 


with  agate,  agatej,  strlit; 
package  tody  GEMIO  is 
use  agate,  agatej,  strlit; 

STDIO  W  :  CONSTANT  integer  :=  15 
STDIO ~R  :  CONSTANT  integer  :=  0! 


procedure  ?UT_LN  (  Idev  :  in  integer;' 

w_class  :  in  access_class ; 
str  :  in  string  )  is 

—  put  a  string  on  device  Idev  with  cr  and  If 

out_tuf  :  string(  82  ); 
success  :  integer; 
vt_sio  :  wt_seq_struct ; 
size.-str  :  Inteier; 

CR  : "CONSTANT  integer  :=  13? 

LJ  :  CONSTANT  integer  :=  10? 

tegin 

out_tuf  :=  str; 
size_str  :=  length(  str  ); 

out_tuf  out_tuf  &  char_to_str(  charac ter  'val (  CR  )); 

out_tuf  :=  out_tuf  &  char_to_str(  character 'val (  LF  )); 
wt_sio .device  7=  Idev; 

wt_sio ,data_of f  :=  out_tuf 'ADDRESS  +  i; 
wt~sio .data^seg  : =  get~ss()J 
wt”sio. count  :=  size_str  +  2; 
wt^sio. class  : =  v_class? 
wrlte_sequen tial (  vt_sio,  success  ); 

end  PUT  LN ; 


procedure  GIT_STR  (  Idev  :  in  integer? 

r_class  :  out  acress_cla ss: 
str  :  out  string”)  is 

get  a  string  fror  device  Idev. 

in_tuf  :  string(  62  ); 
success  :  integer? 
rd_sio  :  rd_seq_struct; 
ra”ret  :  rd2seq”return ? 
size  str  :  integer; 


rd_sio ,data_off  :=  in_buf  'ACTRESS  +  i; 

rd”sio .device  :=  IdevT 

rd~sic .data_seg  :=  get_ss(); 

read_sequent ial (  rd_sio,  rd  ret,  success  )? 

in_buf(  0  )  :=  charlc ter 'val (  rd_ret. count  ); 

str  : =  in_buf? 

r_class  :=  rd_ret . cla ss ? 

end  SET  STR 5 


procedure  ?UT_STR  (  ldev  :  in  integer* 

w_class  :  in  access_class? 
str  :  in  string  )  is 

put  a  string  on  device  ldev. 

out_tuf  :  string? 
success  :  integer? 
vt_sio  :  wt_seq_struct? 
size-_str  :  Integer? 

begin 

out_buf  :=  str? 

sizi_str  :=  length(  str  )? 

wt_sio .device  :=  ldev? 

vt_sio  .data_off  :=  ou  t_buf 'ADDRESS  +  1? 

wt_sio .data_seg  :=  get_ss()? 

wt_sio. count  :=  size_str? 

wt_sio. class  :=  w_class? 

vrfte_sequential (”wt_sio,  success  )? 

end  PUT  STR? 


procedure  PTJT_DEC(  ldev  :  in  integer? 

v_class  :  in  access._clas s ? 
dval  :  in  integer  )  is 

—  put  the  string  equivalent  of  a  integer  on  the 
screen . 

out_buf  :  string(  10  )? 
begin 

out_tuf  :=  Int_to_str(  dval  )? 
put”str(  ldev  ,”v_class,  out_tuf  )? 


terrrina 


end  PUT  DEC? 


procedure  PUT_SUCC(  in_str  :  in  string? 

dec_val  :  in  integer? 

w_clas  s  :  in  access_class  )  is 

print  a  string  and  an  integer  on  device  attach 
slot  S T D 1 0 _ V/ 

(should  be  a  serial  terminal)  . 

begin 

put_str(  STDIO_W,  w_class,  in_str  )? 
put_dec(  STDI0_W,  v_class ,  dec_val  )? 
put_ln(  STDI0_W,  w_class,  )? 

end  FUT_SUCC? 

procedure  TYFI_ANY_KEY_TO_CONT INUZ( w_class  : 

access_class )  is 

rd_str  :  string? 
rd_class  :  acces s_class ? 

begin 

put_str  ( STDIO_V.',w_class ,  "  tjpe  any  key  to  continue 
get~str  (STDIO’R, rd_class ,rd_str  )  ? 
put~ln  ( STDIO_W ,  w_class,rd_str) ? 

end  TYPE  ANY  KEY  TO  CONTINUE  ? 


procedure  BLX_SCR  (  ldev  :  in  integer? 

w_class:  in  access_class )  is 

—  clear  screen  and  home  cursor 

out_buf  ;  string? 
success  integer? 
vt  sio  :  wt  seq  struct? 

ESC  :  CONSTANT  integer  :=  27? 

7  :  CONSTANT  integer  :=  45? 

begin 

out_buf  : =char_ to_s tr (cha rac ter 'val (ESC ) ) ? 
out_buf  :=out_buf  &  c  ha  r_  to_s  t  r  ( cr.a  rac  te  r '  va  1  ( Y )  )  ? 
w t_si o .device  :=  ldev? 
vt~sic .data_cff :  =  out_buf 'ADDRESS  *  1? 
wt_slo.data_s eg: =ge t~ss (  )  ? 
w  t  sio .count :=2? 


—  This  package  contains  declarations  for  the 

—  application  programs 


with  agate,  ari; 
package  TABLES  is 
use  agate,  arli 


MAX  PROC 
MAX  LEVELS 
TOP“SECRET 
SECRET 

CONFIDENTIAL 

UNCLASSIFIED 


CONSTANT 

CONSTANT 

CONSTANT 

CONSTANT 

CONSTANT 

CONSTANT 


integer 

integer 

integer 

integer 

integer 

integer 


type  R1_PARAMETERS  i 
entry_stack  : 
mentor_stack  : 
seg_number_stack 
e'ntry^code  : 

mentor_code  : 

seg_number_code  : 
entry_data  : 

mentor_data  : 
seg_number_data  : 
evn_count  ”  : 

evn_count_data  : 
end  record? 


s  record 
integer  * 
integer; 

:  integer? 
integer; 
integer ; 
integer; 
integer ; 
integer? 
integer; 
integer; 
integer ; 


type  P.1_PARAM  is  array  (l..MAX_PROC  )  of  rl_parameters ; 


type  LEVZL_RECORD  is  record 

min  “  :  access_class » 

max  ;  acce s s_c la s s J 

end  record; 


type  USER_LEVEL  is  array  ( 0 . . MAX_LEVELS )  of  level _rec ord ; 


type  SHIP_PARAM  is  record 


paraml 
param2 
param3 
f lag_z 
end  record; 


integer; 
integer? 
in  teger? 
boolean; 


type  RADAR_INPUT  is  record 


[to 


m 


radarl 
radar2 
radar3 
f lag_z 
end  record? 


in  teger ; 
integer; 
in  teger; 
boolean ; 


type  CHAFF_OUT  is  record 
chaff!  :  integer? 
chaff2  :  integer? 
chaff3  :  integer; 
flag_z  :  hoolean? 
end  record? 

type  TFST_MESSAGE  is  record 
reel-  :  integer? 

rec2  :  integer? 

result  :  integer; 

flag  :  hoolean? 

end  record? 


procedure  L0AD_PARAI“!_T0_4_CHLD  (  init  :  in 

rl_process_def ? 

ch_para  :  out  rl_pararr); 

procedure  LOAD_ACCESS_CLASS (  init  :  in  rl_process_def ? 

usr  access  :  out  user  level); 


end  TABLES? 
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with  agate,  arl  * 
package  tody  TABLES  is 
use  agate,  arl  ; 


procedure  L0AD_PARAM_T0_4_CHLD  (  init  :  in  rl_process_def 

ch_para  :  out  rl_param) ~is 


load  the  segments  specifications 

INITIAL  :  CONSTANT  integer  :=  31 ; 

NEXT_NUN>3ER_FREE  :  CONSTANT  integer  :=  40; 

prep  :  rl_parameters ; 

tegin 

,f  or  i  in  1 . . 4  loop 

prep . entry_s tack  :=  i? 

prep.mentor_stack  :=  INITIAL; 

prep . seg_numter_stack  :=  INITIAL  +  i? 

prep.seg_nurrter_code  :=  INITIAL  +  i  +  4; 

prep.entry_code  :=  i  +  6; 

prep.rrent  or_code  ini  t .  ini  t  ial_seg  ( 2 ) » 

prep .en try_data  :*  i  +4; 

prep.rrent  or  data  :=  INITIAL; 

prep . seg_numter_da ta  :=  NEXT_NlTMEER_FREE  +  i  -  i; 

ch_para ( i  )  : =  prep ; 
end  loop; 

end  LOAD  PARAM  TO  4  CHLD  J 


procedure  LOAD_ACCFSS_CLASS  (  init  :  in  rl_process_def ; 

usr_access  :  out  uier_level  )  i 

load  user  security  levels 

usr_level  :  level_record ; 

BEGIN 

usr_level  .rrin. compromise. int?  :=  0i 
u$r_level .mi n. compromise  .inti  :=  0» 
usr~level . min . integri ty  .  into  :=  05 
u$r”level .min . i r tegri ty  .  i n 1 1  :=  21504; 

usr~level. max. compromise  .into  :=  6; 


usr_level .  ma  r. compromise  .inti 
usr^ level. mar. integrity. int0 
usr "level. max. integrity. inti 


=  0; 

=  0; 

=  21504J 


usr_access (TOF_SECRFT )  :=  usr_levei; 


usr_level .min .  compromise. in t? 
usr~level .min. compromise .inti 
usr 3 level .min.integrity.int0 
usr^level. min. integrity .inti 
usr_level .max .compromise .int0 
usr "level .max. compromise .inti 
us r~ level. max.integrity.int0 
usr "level .mar.integrity.irtl 

usr_access ( SECRET )  :=  usr_level; 


usr_ level. min. compromise.intZ 
usr "level .min. compromise. inti 
usr_ level. min. integrity.intC 
.u  sr  "level,  mi  n.integrity. inti 
usr "lev el .max .compromise .int0 
usr_level .max .compromise .inti 
usr3level.mar.integrity.int0 
usr _ level .max.integri ty .inti 


=  0? 

=  0? 

=  0; 

=  21504; 

=  4; 

=  0; 

=  0; 

=  21504; 


0; 

05 

0; 

21504; 

2; 

0; 

0; 

21504? 


usr_access (CONFIDENT! AL )  :=  usr_level? 


level .min. compromise .int0 
level . rri  n.c ompromise . inti 
level .min. integrity .in t0 
level .min. integrity. inti 
level .max .compromise  .int0 
level. max. compromise. inti 
lev el. max. integrity. int0 
level  .max  .  integri  ty  .  ir.tl 


0; 

0; 

e; 

21504; 

0; 

0; 

0; 

21504; 


usr  access(UNCLASSIEIED)  :=  usr  level? 


end  LOAD  ACCESS  CLASS? 


end  TABLES; 


m 


Specif ication  for  the  Create  Process  Facka 


with  agate,  agatej,  arl,  alib,  alibj,  rranag,  gemio,  tables 
package  CRPROCE  is 

use  agate,  agatej,  arl,  alib,  alibj,  manag,  gemio,  tables 


procedure  FILL_INIT( 


init  :  in  rl_process_def ? 
ch_lnit  :  out  rl_process  def; 
ch_access  :  in  level  _recorci  )  ; 


procedure  TO_CREATE_PROCESS(  init 

ch_pa  ra 


(  init  :  in  rl_process_def; 

ch_para  :  in  rl_parameters; 
ch_Iccess  :  in  1 evel_rec ord ; 
prcces  :  in  integer; 
synchr_seg  :  in  integer? 
success  :  out  integer); 


end  CRPROCE; 


This  package  contains  the  procedure  to  create 
processes 


with  agate,  agatej,  arl,  alih,  alitj,  gemio,  nanag,  tables; 
package  tody  CHFHOCE  is 

use  agate,  agatej,  arl,  alit,  alibj,  gemio,  manag,  tables! 

—  Constants  for  device  slots. 

5TDIC  W  ;  CONSTANT  integer  :=  1J 
5TLI0 :  CONSTANT  integer  :=  0; 

I0_P0ftT  :  CONSTANT  integer  ;=  0;  —  port  zero  for  main 

process 

procedure  FILL_INIT(  init  :  in  rl_proces s_def ; 

ch^init  :  out  rl_process_def ; 
ch_access  :  level_record  )~is 

fill  in  the  initial  process  record  of  a  child 
process  . 

called  by  to_create_prccess 

begin 

ch_init.cpu  :=  init.cpu! 
ch~init .num_cpu  :=  init . r.um_cpu; 
ch_ini t .num~kst  ;=  init .  num~ks t ; 
ch_ini t .root_access  :®  init7root_accessJ 
ch_ini t . s_seg  : «  31 

ch_init. resources. priority  :  =  i ni t . res ources . pri cri ty  ; 
— same  as  parent. 

b24_f rm_ir. teger(  *0,  ch_init  .resources .memory  ); 
ch_Ini tTresources .processes  :=  2! 
ch~ini t . resources . segmn ts  :=  103* 

this  will  be  modified  with  the  specific  access  class  of 
each  process 

ch_init .resources .min_class  :=  ch_access  .mi n* 
ch_init. resources. max~class  :=  ch]]access  .max  ; 
ch  init .r irg_num  :=  tyte(  1  ); 
ch”ini t.sp2  7-  0; 

end  FILL  INIT; 


init  :  in  rl_process_def ; 
ch_par  :  in  rl_parameters ; 
ch  access  :  in  level  record! 


procedure  T0_CREATF_PH0CIS5 ( 


proces  :  in  integer; 
synchr_seg  :  in  integer? 

success  :  out  integer  )  is 

process  creation 

chld_seg  :  rl_seg_struct ?  —  rl_addr_array  for  child's 

segment 

rh_init  :  rl_process_def ?  —  rl_process_def  for  child 

seg_rec  :  create_seg~struct ?  —  usid  to  create  stack  segment 
segl_mkn  :  mk_kn_s truct ?  —  used  to  make  known  stack 

segmen  t 

segl_ret  :  mk_kn_return ? 

crt_rec  :  rl_cp_struct ?  —  create  process  structure 

ch_seg_list  :  seg_array? 

w_class  :  access_class  I 

evc_value  :  integer? 

stack_size  :  integer? 

seg_mgr_ty tes  :  integer? 

def_off  :  integer? 

def^seg  :  integer? 

rl_def_size  :  integer? 

—  constants  for  determining  stack  size 

rl_stack_si ze  :  CONSTANT  integer  : =  15#FF F#? 
vect_size  :  CONSTANT  integer  :=  4? 

BEGIN 

w_class  :  =  ch_access  .mir.  ? 

segl_mka. mentor  :=  ch_pa r .me nt or_code ? 
segljrkn. entry*  :=  ch_pa r . entry_code ? 
segl_mkn . seg_numter  :=  ch_pa r . sig_numter_c ode ? 
segl^mkn . seg”mode  : =  r_e?~ 
segl  mkn.prot  level  :=  byte(  1  }? 

segl~mkn.gate_aumher  :=  N'JLL_INDFX ?  —  no  gate 

makekn own_segment (  segl_mkn,  segl_ret,  success  )? 
if  success  /  =  0  then 

put_succ ( "success  value  is  ", success, w_class) ? 
put~ln(STDIO  W, w_class ,""  )  ? 
end  if T 


address  spec  for  child's  stack 

chld_seg. seg_numher  :=  ch_pa r . seg_numter_stack? 
chld_seg . seg’mode  :=  r_w?~ 
chld_seg. swapi n  :=  TRUf? 
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chld_seg. protect  :=  tyte(  1  ); 
crt_rec .rl_addr_array (  0  )  :=  chld_seg; 


address  spec  for  child's  code 

chld_seg. seg_number  ch_par.  seg_number_code ; 
chld_seg.seg_mode  :=  r_e; 
chld~seg . swapin  :=  TRUf; 
chld“seg. protect  :=  byte(  1  ); 

crt_rec .rl_addr_array (  1  )  :=  chld_segj 

address  spec  for  child's  mentor 

chld_seg . seg_number  :=  synchr_seg? 
chld~seg . seg~mode  :=  n_a? 
chld_seg. swapin  :=  TRUE; 
chid “seg*pro tect  :=  byte(  1  ); 

crt_rec . rl_addr_ar ray (  2  )  :=  chld_seg; 

address  spec  for  trap  handler  segment 

chld_seg. seg_numter  :*  init .initial_seg(4); 
chld_seg.seg~mode  :=  r_e; 
chld”seg. swapin  :=  TRUf; 
chld_seg. protect  :=  byte(  1  )» 

crt_rec .rl_addr_array(  4  )  :=  chld_seg; 


address  spec  for  child's  data 


chld_seg . seg_number  ch_par . seg_number_data J 
chld~seg. seg’mode  :=  r_w;~ 
chld_seg . swapi n  :=  TRUE; 
chld_seg. protect  :=  byte(  1  ); 


crt_rec .rl_addr_array(  2  )  :=  chld_segj 


fill  the  order  in  which  the  segments  will  be  passed 


ch_seg_list (0) 
ch3seg_list( 1 ) 
ch'seg^list ( 2 ) 
ch“seg"llst(2) 
ch_seg_list(4) 


ch_par .  seg_rumber_stacic ; 
ch_par . seg_number_code ; 
syn  chr_seg; 

ch_parTseg_number_d  ata; 
init . initial_seg( 4) ; 


calculate  required  staclr  size. 

(in  the  future  will  calculate  based  on  data  in 
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file  header 

—  but  now  just  use  constant.) 

seg.mgr.by tes  :=  (  stack.header 'SIZE/S  ) 

(  initTnum.kst  *  (  kst.entry  'SIZE/S  )) 

+ 

(  kst.header 'SIZ2/S  )! 

stack.size  :=  rl_stack_size  +  vect.size  +  seg_mgr_by tes 

+ 

(  rl_process_def 'SIZE/9  ); 

create  and  make  known  child's  stack  segment 

seg.rec .ment or  ch_par .mentor_stackJ 
seg.rec . en tryx  :=  ch_par  .ent ry _s tack; 
seg’rec.limi t  :=  stack.size  -  I; 
seg”rec .class  :=  ch.access .min ; 

create.segme nt (  seg.rec,  success  )> 

if  success  /=  2  then 

put_succ( "success  value  chsta  is  ”  .success, w.class) ; 
put~ln  (STEIO  V ,  w  class,’"’); 
end  if? 

segl.mkn. mentor  :=  ch_pa r .ment or.stack; 
segl~mkn .entryx  : =  ch~p5r  .entry.stack? 
segl.mkn. seg.number  :=  ch.par . seg. number. stack; 
segl^mkn . seg^roode  :=  r_w ; ~ 
segl.mkn .prot.level  :=  byte(  1  ); 
segl~mkn .gate“r.umber  :=  NULL  INDFXJ 
segl.mkn . gate.prot  :=  byte!  2  ); 

makeknown_segrrent(  segl_mkn,  segl.ret,  success  j; 

if  success  /=  0  then 

put _succ ("success  value^mksta  is  "  .success, w.class) ; 
put”ln(ST2I0_W,w_class  , ’’") ; 
end  if; 

swapin.segment (  ch.par . seg_nunber_stack ,  success  ); 

if  success  /=  0  then 

put _succ( "success  value  swapsta  is 

"  ,  success  ,w  class  ) ; 

put  In (STEIO  W.w  class,""); 
end  if; 

—  create  and  make  known  child's  data  segment 
seg.rec  .ment  cr  :=  ch_par  .merstcr.data; 


seg_rec .entry*  :=  ch_par .entry _data ; 
seg’rec .limit  :=  test  jnessage'size/8; 
seg^rec .class  :=  ch_access  .mir. ; 

c reate_segment (  seg_rec,  success  )» 

if  success  /=  0  then 

put_succ(  ” success  valueftchdat  is  "  .success  ,w_cla  ss  )  ; 
put ”ln  (  STDIO  W ,  w  class,’"’); 
end  if? 

segl  mien. mentor  :=  ch_par .ment or  data; 
segljnkn  .entryx  :=  chjoar  .entry_Jata ; 
segl”mkn . seg_number  :  =  ch_par . sig_numter_da ta ; 
segl”mkn . seg^^ode  : =  r_v; 
segl^mkn .prot_level  :=  byte(  1  ); 
segl”mkn.gate~numter  :  =  NULL_INBFX; 
segl_mkn .gate_prot  :=  byte!  0  ); 

makeknown_segment(  segl_mkn,  segl_ret,  success  ); 

if  success  /=  0  then 

put_succ( ’’success  value  mkdat  is  ”,  success  ,w_class ) ; 
put~ln ( STDIO  W,w  class,"”); 
end  if T 

swapir_segment (  ch_par . seg_rumter_data ,  success  ); 
if  success  /=  0  then 

put  sued  "success  value  swadat  is  ”,  success  ,w_class )  ; 
put “in ( STDIO _W,w_c lass  ? 
end  if! 

—  fill  in  childs  rl_process_def 
fill_init(  init,  ch_init,  ch_access  ); 

—  determine  segment  and  offset  of  rl_process_def  initial 
record 

def_seg  :=  lib_mk_sel(  ldt_tatle, 

ch  par . seg_number_stack  ); 

def_off  :=  stack_size  -  (  vect_slze  +  seg_mgr_by tes  + 
rl_pr ocess_def 'S IZE?S  ); 

move  ch_init  into  proper  place  in  child's  stack  segment 

rl  def^size  :=  (  rl  process_def 'SIZE  )/£; 
move_bytes(  get_ss(T,  ch_inlt 'address ,  def_seg,  def_off, 
rl  def  size  i; 
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—  fill  in  remainder  of  create_process_structure 

crt_rec.ip  :=  128J  —  skip  command 

file  header  (82  hex) 

crt_rec.spx  :=  def_off»  —  set  childs  stack 

pointer 

crt_rec.spl  :=  stack_size  -  (  vect_size  +  seg  mgr  bytes 

crt_rec.sp2  :=  05  —  no  ring  2  stack 

crt_rec .vec_seg  :=  0J  —  rl  address  array 

elenent  0 

crt  rec.vec  off  :=  stack  size  -  vect  size; 
crt”rec .child_num  ~  : =  proces-15 

crt_rec .priority  :=  ch_init. resources. priority? 
crt_rec  .memory  :=  ch_init  .resources  .memory.; 
crt_rec .processes  :=  ch_iai t . resources . processes  5 
crt_rec .segmnts  :=  ch_ini t . resources . segmnt s5 
crt_rec .min_class  :=  ch_ini t .resources .min_class ; 
crt“rec .max“class  :=  ch“in i t .  re  sources  .max~class ; 

—  read  event  count  so  we  prepare  for  synchronization 
'read_evc(syncbr_seg,evc_value,  success  ); 

create  the  process 

create_process (  crt_rec,  success  ); 
if  success  /»  0"THEN 

put_su cc(  ”  create  process  success  =  ",  success, 

w  class  ); 

end  if; 

awa it ( synchr_seg,  evc_value+l,  success  ); —  blocks  and 

await 

—  "goto”  process  created 

end  TC  CREATE  PROCESS  ; 
end  CRPROCE; 
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APPENDIX  C 

TEST  PROGRAM  LISTING 

This  program  was  developed  following  the  general  format 
of  the  application  program  in  Appendix  A.  The  preparation 
of  this  program  to  execute  in  the  secure  environment  is  done 
in  the  same  way  as  the  application  program. 


This  package  controls  the  operation  of  the  test 
program 


with  arl,  alit,  alitj,  agate,  strlit,  man.ag,  tables,  gemic 
crpr oce  5 

package  tody  TOTIN'E  is 

use  arl,  alit,  alitj  ,  agate,  strlib,  manag,  tables,  gerio 


crproce ; 

—  constants 

5TTIO  V  :  CONSTANT  integer 
STDIO”r  :  CONSTANT  integer 
10  PORT  :  CONSTANT  integer 
PPL  :  CONSTANT  integer 

—  variables 


1 ; 

0! 

0;  —  2  port  for  main  urogram 
?; 


i  nit 

t  rl_process_def 

calls 

ch_tatl e 

r  l_par  arr ; 

ch^level 

user_level ; 

seg_'mode 

seg_acces  s_type ; 

ch  tat 

r l_paramet  er s  5 

ch“lev 

level_record  ? 

w_cla  ss 

access_class  5 

class 

access~class; 

rd_class 

acce$s~cla$s 

in”choice 

string? 

test_rec 

tes  t_message; 

mentor 

integer? 

en  tryx 

integer? 

def  seg 

integer? 

def "of f 

integer; 

def _si ze 

integer? 

size 

integer? 

success 

1 n  tege  r ? 

seg_numt.rr 

integer ; 

synchr_seg 

integer? 

choice" 

integer? 

evc_value 

integer; 

procedure  INITIALIZATION  is 

tegi  n 

— necessary  for  all  kerne 


—  attach  serial  port  for  writing 
attach  tew  (I0_P0RT,  STDIOJO? 


—  attach  serial  port  for  reading 


A0-A171  395  MODELLING  OE  A  MULTILEVEL  SECURE  TACTICAL  COMBAT  2/2 

COMPUTER  SVSTEMCU)  NAVAL  POSTGRADUATE  SCHOOL  MONTEREV 
CA  C  B  CAVALCANTI  JUN  BE 


UNCLASSIFIED 


F/G  9/2 


NL 


at tach_ter  UO.FOHT,  STLIO_R); 

—  load  parameters  to  create  up  to  4  children 

load_param_to_4_chld (init,  ch_tatle ) ; 

— load  access  classes  for  Top-Secret,  Secret,  Confidential 
and  Unclassified  . 

load_access_class  Unit,  ch_level); 

—  prepare  class  for  accessing  main  terminal 

w_class  :=  init. resources. min_class; 
end  INITIALIZATION  i 
procedure  STACK_AND_SYNC_CREAT ION  is 
begin 

—  creating  segment  for  stack(parent )  .Will  be  unclassified 

—  so  as  to  obey  compatibility  property  :  segment  compromise 

—  must  dominate  mentor  compromise. 

mentor  :=  init.initial_seg(2) ; 
entryx  :=  5J 

class  :=  init . resources .min  class; 
size  :=  128? 

cr_segment(  ir.it,  mentor  ,  entryx,  size,  cl  ass,  success)  ; 
if  success  /*  0  then 

put_succ ( "success  stack  parent  ",  success ,v_class ) ; 
put  In  (STDIO  V,w  class,"'); 
end  if; 

—  makeknown  this  segment 

seg_mode  : =  r_v? 
seg_number  31» 

mk_segment ( init , mentor , entryx  , seg_number ,seg_mode , success) ; 

if  success  /-  0  then 

put_succ( "success  makekenovn  stack 

parent  .success,  v_class); 
put  In  (STDIO  Vfw  class,"'); 
end  if!  " 
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—  creating  synchronization  segment  . 

mentor  :=  ini t .ini tial_seg(2 ) 5 
entry*  :=  6; 

class  :=  init  .resources .min_classi 

cr_segmen t( init ,ment  or .entry* .size, cl ass .success ) ; 

if  success  /=  0  then 

put_succ( "success  sync  is  , success ,w_class ) ; 
pu t”ln( STD IO_V,v_c lass 
end  if? 

—  makeknovn  this  segment 

seg_mcde  : =  r_w; 
seg_nurrter  :=  511 

mk_segment  ( init  .men  tor  .entry*  ,  seg_r.umher,  seg_mode  .success  ) » 
.if  success  /-  0  then 

put_succ( "success  mkknown  sync”, success, w_class) ; 
put~ln ( STDIO  V,  v  class,”"); 
end  if;  " 

synchr_seg  :=  seg_number; 

—  swapin  this  segment 

swapin_segment (seg_n umber, sue  cess) ; 
if  success  /=  0  then 

put_succ(  "success  swapin tsync”, success, w_class) ; 
put ”ln ( STDIO_W,v_c lass ” ) ; 
end  if; 


end  STACK_AND_SYNC_CREATION; 
procedure  PHOCESS_CRPATION  is 


begin 


put_ln(STDI0_W,v_cla5S, "Begin  Process  Creation”); 
typi_any_key~to_continue (w_class ) ; 


—  start  creating  processes  in  the  system 

—  process  1  ==  >  Store  and  Display 

—  process  2  «  >  Calcl  ->  one  field  passed 

—  process  3  »  >  Calc2  field  passed  every  loop 


ch_tat  ?=  ch_table( i ) ; 
ch~l ev  : =  ch~level(4); 

to_create_process ( ini t  ,ch_tab , 

ch_lev,i , synchr_seg, success) 5 

end  loop; 

end  PROCESS_CREATION  ? 

procedure  MENU  (selection  :  out  integer)  is 
—  Fresent  option  to  execute  each  timing  program 
begin 

put_ln(STEIO_W,w_class ."Execute  with  no  GEMSOS  calls"); 
put“ln(STDIO_W,v“class ,”12  mult/div  30000  times"); 
put”ln(STEIO”V,v”elass  #”  =>  <  1  >”) J 

put  ln(STDIO  W.w  class  , "Exerute  passing  data  4  times"); 
-put"ln(  STDIO~W,w”class ,  ”12  mult/div  ,  30000  times"); 
put~ln(STDIO~V ,v“class , "  ■>  <  2  >"); 

put_ln(STDIO_W,w_class, "Execute  passing  data  p/  loop"); 
put‘’ln(STEIO“V  ,w“class  ,  ”12  mult/div  ,  300  times'); 
put”ln(STDIO~W,v”elass ♦"  =>  <  3  >"); 

put_ln(STDIO”W,w~class , "Exit  =>  <  4  >"); 

get_str(STRIO_R ,rd_class ,in_choice) ; 
if  In  choice  *  "l"  then 
selection  :=  l; 
elsif  in_cfcoice  =  "2"  then 
selicticn  :=  2; 
elsif  in_choice  »  "3"  then 
selection  :=  35 
elsif  in  choice  =  "4"  then 
selection  :=  4? 

el  se 

selection  :=  55 
end  if; 

end  MENU? 

procedure  START  is 
begin 

put_ln(STPIO_W,w_class Prep  to  time  ...  "); 
type  any  key  to  continue  (v  class); 
end  STARTT  -  -  - 


procedure  FINISH  is 
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begin 

put_str(STDIO_W,v_class , 

char  to  str (character  'val (3EL) )) i 
put_ln(STDIO_W,w_class ,  "S-T  0  P  ") J 
type  any  key  to  continue(w  class); 
end  FINISH;  ~ 

procedure  RECFIVF_F^_STO  is 


begin 


def  seg  : = 

lib  mk_sel  (ldt  table, ch  table(l).seg  number  data); 
def _of f  :=  05 

.def”size  :=  test_message 'size  /S » 
move_bytes(def_seg,def_off ,get_ss( ) , 

test_rec'ADDRFSS,def_size ); 


end  RECFIVF_FM_STO  ; 
procedure  PASS_TC_CA1C1  is 
begin 

def _seg  := 

lib  mk  sel(ldt  table, ch  table(2).seg  number  data); 
def  off  7=  0 ; 

def_size  :*  te$t_message'size  /0J 
move_by tes 

(get_ss( ) ,test_rec ' ADDRESS , def _seg, def _of f, def _ size) ; 
end  PASS_TO_CALC 1  ; 
procedure  RECEIVE_FM_CALCl  is 


begin 


def_seg:=lib_mk_sel( Id t_ table, 

ch_table(2) . seg_number_da ta) ; 

def_off  :  =  ?; 

def'size  :=  test_message 'size  /9 ; 
move_bytes( def_seg,def _off ,get_ss( ) , 

test  rec' ADDRESS, def  size); 


end  RECEIVE_FM_CALC1  ; 
procedure  PASS _T0_CALC2  is 


begin 


def_seg  : = 

lib  mk  sel(ldt  table, ch  table(3).seg  number  data); 
def  off  :=  05 


*.v 


def_size  :=  test_message'size  /6i 
move_bytes 

'get_ss ( ) 7 test_rec 'ADDRESS , def_seg ,ief_of f  ,def _si ze  ) ; 
end  PASS _T0_CALC2  ; 
procedure  RECEIVF_FM_CALC2  is 
begin 

def  _seg  :=lib_mlc_sel  ( Id  t._  table  , 

ch  table(3).seg  number  data); 

def  off  :=  0; 

def^size  tes t_mes sage 'si ze  ./£? 

move_bytes (def_seg,def _off ,get_ss( ) , 

test_rec 'ADDRESS ,def_si ze ) ; 

end  RECFIVI_FM_CALC?  ; 
procedure  FASS_TO_STO  is 
begin 

,def_seg  :  = 

Iib_mk_sel (ldt_table,ch_ table (1) . seg_numter_data ) ; 
def  off  :  =  0 ; 

def”size  :=  test_message 'si ze  /8; 
move_bytes (get_ss ( ) t  test_rec 'ADDRESS , 

def_seg,def _of f ,ief_si ze ) ; 

end  PA5S_TO_STO  ? 


procedure  CALC _NO_CALLS  is 

FIRST  :  CONSTANT  integer  :=  1 0000J 
SECOND:  CONSTANT  integer  :=  500; 

begin 

start » 

for  i  in  1.. 70000  loop 

test_rec .result  :=  ((  10000  /  500  )  *  300  )  /  130: 

test  rec. result  :=  ((  10000  /  500  )  *  300  )  /  100? 

test'rec. result  :=  ((  10070  /  500  )  *  300  )  /  100; 

test_rec . result  :=  ((  100C0  /  500  )  *  300  )  /  1Z0; 

end  loop?" 
finish; 

put_ln(STDIC_W,w_class f”now  do  the  same  operation 
twice” )  ; 

put_ln(STDIO_V,w_class  /’calculate  the  loop  control 
time” ) ; 
start ; 


for  i  in  1.  .30000  loop 

test_rec . result  :=  ((  10000  /  500  )  *  300  )  /  100 » 

test”rec . result  :=  ((  10000  /  500  )  *  300  )  /  120? 

test~rec. result  ;=  ((  10000  /  500  )  *  300  )  /  100; 

test“rec. result  :=  ((  12000  /  500  )  *  300  )  /  100; 

test“rec. result  :=  ((  10000  /  500  )  *  300  )  /  100; 

test"rec. result  :=  ((  12000  /  500  )  *  300  )  /  100; 

test”rer. result  :=  ((  10000  /  500  )  *  300  )  /  100; 

test”rec .result  :*  ((  10000  /  502  )  *  300  )  /  100; 

end  loop*” 
finish; 

end  CALC_NO_CALLSJ 
procedure  CALC_ONE_PASS  is 
begin 

start  J 

advance(ch_  tabled ) . seg_number_ stack, success) ; 
read_evc ( sy n oh r _s eg, evc_ value  , iuccess )  5 
await ( synch r_seg, eve _value+l .success ' ; 
receive_fm_stot 
'•'pass_to”caIci; 

advance { ch  table( 2 ) . seg_number_ stack .success ) 5 

read_evc(synchr_seg, eve “value, iuccess) J 

await ( synchr_seg, eve  jralue  +  1 .success ); 

receive_fm_calci; 

pass_to”sto* 

finish; 

advance(ch_tehle(l ) . seg  number  stack , success ) 5 
read_eve( synchr_seg , evc^value .success  )  J 
await ( syncfcr_seg,evc_vaiue+l, success) ; 

end  CALC  ONI  PASS; 


procedure  CALC_PASS_ALL  is 
begin 

start ; 

for  i  in  1 . .300  loop 

advance ( ch_tabl e( 1) . seg_number_ stack, success) ; 
read_evc( sync hr_s eg ,evc“value .iuccess ) ; 
await ( syncbr_seg,evc_value+l, success  ' ; 
receive_fm_sto; 
pass_t  o'calc? ; 

advanceTch_table(3 ) . seg_numter_ stack, success) ; 
r ead_evc ( synchr_seg ,evc  value , success ' ; 
await  t  synchr_seg,evc_vaTuej'l,  success )  J 
receive  fm  calc2; 


end  loop; 
finish; 

end  CALC  FAS S  ALL  ; 


procedure  SELE_DELETION  is 
begin 

test_rec .flag  :=  true; 
for  I  in  1. .3  loop 
def_seg  :  = 

lib  ir ic  seKldt  table, ch  tatle(i)  .seg  number  data); 
def _of f  :=  0;" 

def”size  :=  tes t_message ' si ze  /S; 
movi_bytes  (d ef _seg ,def _of f ,get_ss( ) , 

test_rec "ADDRESS , def  size); 
advance'ch_table( i ) .  seg_num ter _stack, success ) ; 
read_evc( synchr_seg , eve "value , iuccess ) » 
avait(  synchr_seg,evc_value+l, success) ? 
put_succ( "self  deleted  ”  ,i , v_class) ; 

;er.d  loop! 


end  SELE_DELETION; 

procedure  DELETE_PROCESS_SEG*ENT  is 

tegin 

for  i  in  1 .  .3  loop 
child_delete(i-l,  success)? 

terminate_ segment  ( ch_  table  ( i  ) .  seg_number_stack,  success ) 
terminate” segment ( ch”tatle( i ) . seg”r.  umbered  a ta .success) ; 
terminate”segmer.  t  ( ch”table(  i  ) . seg”number”c ode .success )  ; 
delete_segment ( ch_ table ( i ) .men  tor _s tack, I, success  ) J 
dele te ”segmen t ( ch”t able ( i) . men tor^data.i +4, success) ; 
delete_segment ( ch_table ( i ) .men t  cr”code, i+6, success ) ; 
put_succ(  deleted”" ,i ,w_class ) ; 
end  loop? 


end  DELETE _PROCFSS_SEGMENT; 
procedure  DSLETE_MENTOR_SYNC  is 
begin 

delete_segmen t  (init ,i ni tial  seg(2),  6,  success); 
terminlte_segment  (51,  success); 
delete_segment  (init ,lnitial_seg(2) ,  5,  success); 
terminate_segment  (31  .success); 
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end  DELETE  MENTOS  SYNC  ? 


*  - 

i 


procedure  DELETION_ALL  is 
begin 

self_deletior; 
delet e_process_segment ; 
delete~mentor_iync; 
put  ln(STDIO_V,v  class,"  0.  E.  "); 
end  DELETION  ALL  : 


procedure  PRFVENT_TRAP  is 
begin 

success  :  =  0? 

while  success  =  0  loop  . 

success  :  =  0J 
end  loop; 

end  PREVENT_TRAP  J 

~  ########  MAIN  PROGRAM  ########*######*# 

begin 

init  :=  get_rl_def ( ) ;  — must  be  the  first  statement 

lit  set_t racket (1,1,1, in it . resources .min _c lass ) ; 

inllializat ion; 

stack_ard_sync_creation ; 

pr ocess_creation  J 

test_rec . flag  :=  false; 

loop” 

menu(chcice) ; 
case  choice  is 

when  1  =>  calc_no_calls; 
when  2  =>  calc~one_pass; 
when  3  =>  calc^pass.all ; 
when  4  =>  exit; 
when  5  =>  null; 
end  case; 
end  loop; 
deletior_ali; 
prevent_t rap? 


end  TOTIME  ; 
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—  This  Package  simulates  the  store  process  in  the  test 

—  pr  cgrarr 


with  arl,  manag,  gemio,  agate,  tables,  alib,  alibj; 
package  body  SlODiSP  is 

use  arl,  manag,  gemio,  agate,  tables,  alib,  alibj; 
—  constants 


STDIC  *  :  CONSTANT  integer  :=  i; 
STHIO'R  :  CONSTANT  integer  :=  P ; 
ro  FORT  :  CONSTANT  integer  :=  3? 


—  variables 


iait 
w_cla  ss 
tist_rec 
def  seg 
def'off 
def _size 
success 
eve  ch  val 


rl_process_def ; 
access_class; 
test_rrissage; 
integer? 
in tegeri 
integer ; 
in  teger? 
integer; 


procedure  RECFIVE_FM_PARI NT  is 


def_seg  :=  1 ib_mk_se 1 ( Id t_table ,  in i t . in i t ial_seg( 3 ) ) ; 
def'off  :  =  Z; 

def~size  :=  tes t_mes sage 's i ze  /8 ; 

move_bytes /def_seg,def_off,get_ss( ) , test _rec 'ADDRESS, 
def _si ze ) ; 

end  receive_fm_parent; 
procedure  PASS_TO_PARZNT  is 
begin 

def  seg  :=  lib  mk  sel(ldt  table,  init. initial  seg(3))J 
def'off 

def_size  tes t_mes sage  ' si ze  /8 ; 

rrovi_by  tes  'get_ss(),test_rec  'ADDRESS ,  def  _  seg ,  def  _  off  , 
def  size); 


end  PASS  TO  PARENT  ; 


—  MAIN  program 
tegin 

init  :=  get_rl_dsf()> 

—  attach  terminal  to  write 

attach.tew  ( I0_P0RT , STDIO.W )  ? 
w_clasi  :  =  init. resources. min_class; 

— attach  terminal  to  read 

attach_ter( IO_PCRT,STDIO_R); 

put_ln(STBIO_V,v_class , "  STORAGE  AND  DISPLAY  READY  ") 


& 

m 


advance  eventccunt  of  synchro  segment  path  5,6  plsn  £1 
passed  to  child  as  ch  seg_list(2). 

Will  he  called  in  child  as  init  .initial_seg(2) 


advance  (init. iritial_s eg (2), success)? 

. read_evc ( in  it . ini t ial_seg(0 ) , evc_ch_va 1 , success ) ? 
“  avait( init. initial _seg(0' ,  eve _ch_val+l , success ) ? 


loop 


pass_to  parent; 

advanced  nit  .initial  seg(2)  .success); 
read_evc( ini t .ini tial_seg(0 ) , evc_ch_val , success) ; 
await ( in  it.  initial  seg(0) ,evc_ ch_va 1  +  1  .success  ); 
receive  fm_parent?” 

advanced  nit  .initial_seg(2)  .success)  ? 
read _e vc (init . ini t ial_seg(0  )  ,evc_ch_val , success ) ? 
await.  (init.initlal_seg(0).  evc_ch_val+l ,  success  )  ? 
receive_fm_parent ? ” 
if  test  rec.flag  then 
exit? 
end  if? 
end  loop? 


advance(init.initial_seg(2)  .success)  ; 


—  dettach  and  delete 


detach_device( STDI0_R,  success  ) ; 
detach~devi ce ( STDI0~W, success ) ? 
self_dilete(init.inltial_seg(2 ) ,  success) ; 


end  STODISP  ; 


.vS-.v 


—  This  package  performs  or.e  of  the  timing  tests 


with  arl,  manag,  gemio,  agate,  tables,  alit,  alitji 
package  tody  CALC1  is 

use  arl,  manag,  gemio,  agate,  tables,  alib,  a  1 i b j ; 

—  constants 

STDIO  W  :  CONSTANT  integer  :=  15 
STDio’R  :  CONSTANT  integer  :  =  05 
I0_PC5T  :  CONSTANT  integer  :=  5? 

—  variables 

init  :  rl_proces s_def ; 

w_class  :  access_class; 

test_rec  :  test_missage» 

def_seg  :  integer; 

def'off  :  integer? 

def_size  :  integer? 

success  :  integer! 

evc_ch_val  :  integer? 


procedure  RECEIVE_FM_PARENT  is 
begin 

def  seg  :=  lib  mk  sel(ldt  table,  init. initial  seg(3)); 
def'off  :=  0?  ~ 

def_size  :=  test_mes sage ' si ze  /8? 
movi  bytes(def  seg, def  off, get  ss(), 

test_rec 'ADDRESS, ief_$ize); 

end  RZCEIVE_FM_PARENT? 
procedure  FASS_TO_PARSNT  is 
tegi  n 

def_seg  :=  lib_mk_se 1( Id t_table  ,  ini t . ini t i al_seg( 3) ) ; 
def’off  :=  0; 

def^size  :=  test_message 'size  /S ; 
move_bytes( get_ss(),test_rec 'ADDRESS , 

def_seg,def_off,def_size); 

end  PASS  TO  PARENT  ; 


MAIN  FROORAM 


■begin 

init  :=  get_rl_def ( ) ; 

—  attach  terminal  to  write 

attach  tew  (10  PORT.STDIC  V.’); 
w_class  :=  iniT.resources7min_class; 

— attach  terminal  to  read 

attach_ter( I0_P0RT,STDI0_R) ; 

put_ln(STDI0_W,w_ class  , "  CALC  ONI  PASS  READY  ").* 

—  advance  eventcount  of  synchro  segment  path  5,6  plsn  51 

—  passed  to  child  as  ch_seg_list (2 ) . 

—  V- ill  he  called  in  child  ai  in  i  t .  in  it  ial_seg(  2  ) 

advance  (init. init3al_seg(2), sue  cess); 
read_evc (init. initial _seg(0 ) , eve _ch_val, success); 
await ( ini t . ini t ial_seg( 0 ) , evc_ch2val+l .success ) ; 


loop 

receive_f n_parent ; 
if  test  rec.flag  then 
exit; 
end  if; 


for  i  in  1.. 30000 

loop 

test_rec. result  := 

(( 

10000 

/ 

500 

) 

300 

)  / 

100; 

test_rec . resul t  := 

(( 

leoeo 

/ 

500 

\ 

J 

S|% 

300 

;  / 

100; 

te st_rec . resul t  := 

( ( 

10000 

/ 

500 

) 

* 

300 

)  / 

100 ; 

test~rec . resul t  := 
end  loop; 

(( 

10000 

/ 

500 

) 

300 

)  / 

130; 

pass_to  parent; 

advance7init.initial_seg(2),success); 
read_evc (init . ini t ial_seg( 0 ) , evc_ch_val .success) ; 
await(init.initial_sei(0) , evc_ch2val+l .success  ) ; 
end  loop; 

ad vance(init.initial_seg(2), success); 

dettach  and  delete 

detach_devi ce ( STDI0_R ,  success); 
detach_device( STDI0_W .success) ; 
self^del  ete  ( ini  t .  i’ni  tial_seg(  2 ) ,  success); 


end  CALC1  ; 


with  arl,  manag,  gemio,  agate  ,  tables  ,  alib,  alibj; 
package  body  CALC2  is 

use  arl,  manag,  gemio,  agate  ,  tables  ,  alib,  alibj; 


—  constants 

STD 10  W  :  CONSTANT  integer  :=  1J 
STDIO_R  :  CONSTANT  integer  :=  05 
IO_?ORT  :  CONSTANT  integer  :=  6? 

—  variables 

init  :  rl_process_def ; 

w  class  :  access_class * 
tist_rec  :  test  jnissage ; 
success  :  integer* 
evc_ch_val  :  integer? 

def_seg  :  integer* 
def^off  :  integer; 
def^size  ’  :  integer? 


procedure  PASS  JTO_PARENT  is 
begin 

def  seg  :  =  lib  mk  sel(ldt.  table,  init .  initialises  (3 )) ; 
def “o f f  :=  0? 

def^size  :=  test_message  'size  /S; 
move_bytes (get  ss(),test  rec'ADDRESS, 

"def_seg ,def _of f ,def_si ze  ) ; 

end  PASS  TO  PARENT  ? 


procedure  RECEIVE_FM_PARINT  is 
begin 

def  seg  :=  lib_mk_sel(  Id  t_table,  ini  t .  ini  t  ial_seg(  3) )  '* 
def”off  :=  0J 

def’size  :=  test_message 'size  /8? 
move_bytes(def_sig,def _of f ,get_ss( ) . 

test_rec  ADDRESS, def _size) * 

end  RECEIVE_i’M_FAREMT; 


—  MAIN  PROGRAM 
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attach  terminal  to  write 


attach_tew{ I0_P0RT ,STDI0_V ) ; 
w_class  : =  inlt .resources. min_class» 

attach  terminal  to  read 

attach_ter(IO_?ORT,STDIO_R); 

put_ln(STDIO_W,w_class,"  CALC2  PASS  EVERY  LOOP  READY"); 

Advance  the  eventcount  of  the  synchronization  segment 
path  5,6  ,  plsn  51  ,  passed  to  child  as  ch_seg_list(2). 
Will  he  recognized  in  child  as  init. initial_seg(2)  . 

advance ( ini t . initial_seg(2  )  .success ) ;  —  this  will 

permit  creation  of  processesto  go  on 

•read_evc ( ini t . ini tial_seg( 0 ) , evc_ch_val  .success ) ? 

—  stack  to  sync 

await (ini t. ir i tial_seg( 0 ) , eve _ch_val +1 , success ) ; 
control  sent  tack  to  creation  of  processes 

loop 

receive_fm_parent » 
if  test  rec.flag  then 
exit ; 
end  if? 

test_rec. result  :=  f(  1000?  /  500  )  515  300  )  /  100 

test^rec . result  :=  ((  10000  /  500  )  *  300  )  /  100 

test  rec. result  ;*  ((  '10000  /  500  )  *  300  )  /  100 

tesOec. result  :=  ((  10000  /  500  )  *  300  )  /  100 

pass_to  parent; 

advanceTinit .initial_seg(2) .success); 

read_evc (init.indtial_seg(0) ,evc_ch_val .success) ; 

awai t ( init .in it ial_seg(0 7 ,evc_ch”val+l , success  )5 


end  loop; 

advance (init. initial _seg (2 )  .success  ) ; 

detach  and  deletion 

detach_device(STDIO_R, success) ; 
detach3device(STDI0”W, success ) ; 
self _delete( ir  i t . lniti al_seg( 2) .success ) ; 


end  CALC2J 
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APPENDIX  D 

SIMPLE  ACCESS  PROGRAM  LISTING 
This  program  presents  a  very  simple  program,  with  the 
purpose  to  show  the  basic  steps  necessary  to  be  able  to 
access  the  secure  system.  Different  from  non-secure 

systems,  the  terminal  is  not  automatically  a  part  of  the 
system.  and  as  shown  in  this  program,  a  GEMSOS  gate  call  is 
necessary  to  include  a  terminal  in  the  system. 


Ill 


Sample  program  to  access  the  system 


pragma  rangecheck(  of?  );  pragma  debug(  off  )*  pragma 
arithcheck{  off  ); 
pragma  enumtab(  of?  )« 

WITH  agate,  arl,  alibj,  util,  manag  ,gemio; 

PACKAGE  BODY  alo  IS 

USE  agate,  arl,  alibj,  util,  manag  ,gemio  ? 


—  Constants  for  device  slots. 

STDIO  W  :  CONSTANT  integer  :=  l; 

STDI0~R  :  CONSTANT  integer  :=  0; 

I0_F0l?T  :  CONSTANT  integer  :  =  31  —  port  zero  for  main 

process 


—  Variables  used  by  main  program. 

w_class  :  access^class »  —  AGATE 

init  :  rl_procesi_def ;  —  AR1 
mentor  :  integer  i 

entrx  :  integer  ; 

size  :  integer  ; 

success  :  integer; 

class  :  access  class  i 

seg_mode  :  seg_access_type  ;  — AGATE 

seg  number  :  integer  i 

—  Pain 

BFGIN 

init  : =  get_rl_def ( )J  —  AR1 

lib_set_tracket (  1,  1,  1,  init .resources ,min_class  )5 

attach  serial  port  for  writing. 

attach  tew (  I0_F0RT,  STDIOJt  );  —MANAG 
w_class  :=  ini t . resources .mia_class ; 

put_ln(stdio_w,w_class,  "  HELLO  COMPLICATED  WOELD**); 

—  attach  serial  port  for  reading. 

attach_ter(  IO_FORT,  stdio_r)»  —  MANAG 

put_ln(  stdio_w,w_class  ,’‘now  I  will  create  a  segment’*); 
typi_>any_key_to_continue  (w_class)» 
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—  creating  segment  for  STACK  (parent) 

mentor  :=  init .initial_seg(2 )  J 
entrx  :=5; 
size  :=10235 

class  :=  init .resources. min.class! 

cr.segment ( init ,  mentor,  entrx,  si2e,  class,  success); 


Fut_ln(stdio_w,w_class  ,'*now  I  will 

make  the  segment  known  "); 
type.any_key_to.con  tin ue (w_class) ; 

—  makeknown  segment  created 

seg_mode  :=  r_w; 
seg'numter  :=~3i; 

mk_segment ( init ,  mentor,  entrx , seg_number  ,seg_mode , success ) ; 
put_ln( stdio_w ,w_class , ”  Ate  logo  (good  tye)”); 

—  infinite  loop  to  prevent  trap, 
success  :=  05 

while  success  *  0  loop 
success  : =  0; 
end  loop; 


end  alo; 


113 


This 

sysgening 


APPENDIX  E 

SUBMIT  FILES  LISTING 

appendix  presents  the  submit  files  used  for  the 
of  the  application  program,  the  testing  program 


and  the  simple  access  program. 


SUBMIT  Fill  FOR  APPLICATION  PROGRAM 


ts:ld3.cmd 

ks :  k0  .cmd 

ks  :kl .cmd 

ks:k0ii.  cmd 

ks :k2 .cmd 

cs : vl loader . cmd; 2 ; 

ds :vll ogin .cmd  5  2  ,10  5 

ds : nv .ds  J2 , 5  J 

ds :nv  .ds?5; 


ds : t hemal n . cmd  » 5 ,0» 
ds : radar.cmd ; 5 ,7 ; 


I  ds : compute . cmd j 5  ,S? 

"  ds :chaf f .cmd; 5  ,S; 

\  ds t rl trap . cmd J 6; 

'i  end 


ma 


aN\%' 


—  SUBMIT  Fill  FOR  TEST  PROGRAM 


ts 

ks 

ks 

is 

ks 

cs 

ds 

ds 

ds 

ds 

ds 

ds 

ds 

ds 

end 


ld3 . cmd 
k0 .end 
kl  .c/rd 
kOb.cmd 
k2.cmd 

vlloader.cmd; 2; 
vllogin  .c/rd  *2  ,10» 
nv.ds;2 ,5; 

".v  ,ds;£; 
totine.cmd; 5,0; 
st  odisp .end ; 5 ,7; 
calcl.cmd;5,S» 
calc2  .cmd;5 ,9 i 
rltrap . cmd ; 61 


SUBMIT  FILF  FOR  SAMPLE  PROGRAM 


b  s :  1  d  3 .  c  md 
ks:k2  .cmd 
ks :kl .cmd 
ks:k3b. cmd 
ks :k2  .cmd 

csrvlloader .cmd; 2; 
ds  tvllogin .cmd i2 , 13; 
ds : nv .ds  »2 , 5; 
ds :nv . d  s » 5 ; 
ds:alo.cmd;5,0; 
is :rltrap.cmd  »6J 
end 
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